Optimizing IEEE Floating-Point Operations

[... the IEEE FP standard and the various language standards
talk past each other, leaving large grey areas. -John]


It's worse than that -- sometimes the standards flatly contradict each other.
E.g. IEEE 754 says that if you print -0 and read it back in again, you should
get -0, not 0; Fortran says that you can't tell the differences between
printing -0 and 0. Luckily these cases are few; in practice IEEE 754 loses
these battles.


However, when IEEE 754 says ``the implementation must do A'' and a language
standard says ``the implementation is free to do either A or B'',
implementers desiring high performance sometimes improperly take the latter
statement as a license to do B while claiming support for IEEE arithmetic.
As a programmer, sometimes I prefer performance, but usually I prefer
standard, repeatable arithmetic. A good compromise is for implementers to
have a compiler option like `-fast-but-loose' that means ``don't bother to
obey IEEE 754 exactly, just make it run fast.'' Clearly optimizing 0.0*X to
X falls in the fast-but-loose category in an IEEE environment where X might
be a NaN. Some implementers might get by with supporting only the
fast-but-loose semantics, but if so I hope they don't pretend that they
conform to IEEE 754.


Unfortunately, new standards continue to be developed with equally large grey
areas. E.g. a proposed international standard called LCAS aims to provide a
language-independent standard for computer arithmetic, but it ignores all
issues of NaNs, Infinities, -0, etc.


In a more hopeful development, the NCEG group is considering a standard for
IEEE 754 support for Standard C. Let's hope they address the 0*X issue!
--

Return to the comp.compilers page.
Search the comp.compilers archives again.