Compiler Specific Operators

[peters at cubsvax.UUCP]

In article <uw-beave.1825> golde at uw-beaver.UUCP (Helmut Golde) writes:

>3. Built in math functions
>
>If the processor has more than the standard +,-,/,* operators (esp. for 
>floating point), it would be more efficient to have built it operators
>that to perform function calls.  Things like:
>
>$pow$, $sin$, $exp$, $log$, $atan$, etc.
>
>#define's could make these quite portable without sacrificing the speed
>advantage.

What does the draft standard say about things that look like function calls
actually being implemented otherwise?  Things a la FORTRAN's intrinsic
functions:  when I write y=SQRT(x) in FORTRAN, this looks just like any
other function call, but even UNIX's f77 doesn't generate a function call
(I believe), though as far as I know there's nothing in the FORTRAN77
standard to preclude this.  (Then again, I don't know much about the F77 
standard.)

Unless there are good reasons not to do this, a given implementation of C
on some machine could actually implement log(x) without a function call --
by an instruction to a special-purpose processor, or even by software
generated by the compiler that runs on the cpu.  This would preclude the 
need for any #defines.  

Regardless of what the draft standard might say, what do the net guru's feel
about this?

Even if it turns out to be a bad idea, there ought to be a more system-
independent way than #defines of specifying things -- like a compile-time 
option to perform math library "functions calls" by some other means, if 
the other means exist .  This option need only exist on the machines where 
the other means exist....   The use of #defines means either that the writer 
has to worry about such exigencies when he's developing the code, or else 
that the porter (not in the railroad-terminal sense!) has to worry about 
going into the code and adding lines.

Peter S. Shenkin	 Columbia Univ. Biology Dept., NY, NY  10027
{philabs,rna}!cubsvax!peters		cubsvax!peters at columbia.ARPA