Order of evaluation, machine floating point

David Chase rbbb at rice.edu
Fri Mar 6 12:07:47 AEST 1987

> to C compilers, perhaps they should give examples of mechanisms which
> allow optimization to be prevented in other languages.  I would hope
> that such mechanisms are portable.

In fortran, parentheses must be honored.  With machine floating point
numbers, addition is commutative, but NOT associative.  C (as presented to
me by its compilers on Pyramids, Suns, and Vaxes) is NOT terribly strong
on floating point arithmetic, and if the standard permits arbitrary
rearrangement of floating point arithmetic using algebraic non-identities,
then this will continue to be the case.

To thwart flames, let me elaborate "not terribly strong"--first, for
unknown reasons all floating arithmetic is supposed to occur in double
precision.  I realize that K&R said it, but I don't know why.  This slows
down FP performance when you really don't need all the precision.  Second,
several compilers have exhibited bugs compiling "a += b" when a and b are
floats.  For some reason, these compilers decide to perform THAT addition
in single precision.  Someone had to work hard to add that bug to the
compiler; if "a += b" is the same as "a = a + b", and all floating
additions are done in double, then why should "single-precision-floating-
addition" even be in the code generator's vocabulary?

Again, let me stress that in some cases you DO NOT WANT double precision
arithmetic.  In some cases it is not worth the extra time and you really
don't care that it gives you a better answer.

(To digress...) Given all this, I found it rather amusing to hear that
someone had written a high quality square-root routine in C.  Voices from
my past say:  "On which machine?  Using which compiler? How fast does it
run?"  Writing that stuff in C makes unwary people think that the code is
actually portable; it is not.  Someday, everyone will speak IEEE and
things will be a little bit safer, but they don't yet.  Sometime long
after everyone speaks IEEE I might begin to trust the compilers (for
instance, do you know for sure that the compiler correctly translates your
floating point constants to their best internal representation?  How about
the I/O library?  Given the record of C compilers so far, I'll bet there's
at least one case where it doesn't yield the best answer.)


More information about the Comp.lang.c mailing list