Compiler Specific Operators
peters at cubsvax.UUCP
peters at cubsvax.UUCP
Sun Jul 13 03:59:23 AEST 1986
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
More information about the Comp.lang.c
mailing list