Compiler Specific Operators

[der Mouse]

[>>> and >>>> blather about coding some functions in-line]
>> Apparently the committee (or a large faction thereof) is quite
>> concerned about ensuring that there is some easy way to ensure a
>> `real function call'.
> Yes, apparently so, but WHY?  What the hell difference does it make,
> from the user's point of view?  That is, why should he ever be
> anything other than happy, if some alternative invoked by the
> compiler produces faster-running code?

     Just when you thought a topic had been beaten to death....

     There are many reasons.  Maybe I have a function j and I don't
realize that the compiler wants to try to in-line code Bessel
functions.  Maybe I want my own sin() and cos(), for example, perhaps
all the calls to sin() and cos() should remember their arguments and
compute the other function as a side effect to speed up the common case
of sin(x) and cos(x) in succession (and I can't afford the time to
rewrite my code to use sincos() or something similar).  Maybe I want to
do something with a pointer to the function (not that this prevents
in-line coding of other uses).  Maybe I am writing a game like
phantasia, where a character has the attribute of sin, and I want to
have a function sin() which has nothing to do with the sine function.
Maybe I want to be able to set breakpoints on entry to sin().  Maybe I
want to save text space badly enough to be willing to accept the
performance disadvantage (ROMing the code maybe, you don't always want
to optimize for speed).
-- 
					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: utcsri!mcgill-vision!mouse at uw-beaver.arpa

"Come with me a few minutes, mortal, and we shall talk."
				- Piers Anthony, Bearing an Hourglass