Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Complex Instructions
Summary: Maybe the people they checked with did not know how to use it.
Message-ID: <1244@l.cc.purdue.edu>
Date: 21 Apr 89 11:22:22 GMT
References: <807@microsoft.UUCP< <92634@sun.uucp< <13322@steinmetz.ge.com> <5965@pdn.paradyne.com>
Organization: Purdue University Statistics Department
Lines: 25

In article <5965@pdn.paradyne.com<, alan@rnms1.paradyne.com (Alan Lovejoy) writes:
< In article <17363@cup.portal.com< bcase@cup.portal.com (Brian bcase Case) writes:
< <>On the subject of calling conventions, I just had my first look at a
< <>68030 manual.  I know, I'm way behind the times, but it was supposed to
< <>be just more of the same.  Why did Motorola delete CALLM?
< <
< <Did they really do this?  Maybe it is because the PMMU subset on the 030
< <can't support the protection semantics, but I'm not sure about that.  Maybe
< <it's because nobody used the instruction.  :-) :-)
> 
> I heard that they checked, and nobody was using the instruction.  I don't  
> remember now what the motivation for dropping CALLM was, other than lack
> of use.  That seems like sufficient justification in itself.

Could this be another example of the vicious cycle?  The language does not
use the instruction, therefore the instruction does not get used, therefore
the instruction gets dropped.  Which algorithm I use depends on the hardware
instructions; if the instruction is not there, I may very well know that 
simulating the instruction is too costly to consider, so it would even be
impossible to tell from a careful examination of code that it would be
desirable.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)