Re: floating point

William D Clinger wrote:
...
> The basic problem is that the IEEE standard was conceived as a
> standard for hardware, and says scarcely a word about high level
> languages or compilers. IEEE Std 754-1985 goes to great lengths to
> ensure that IEEE floating point arithmetic is predictable at the
> hardware level, but Kahan himself has urged compiler writers to use
> extended precision for intermediate results, without seeming to
> appreciate how this leads to unpredictable floating point arithmetic
> at the language level, where almost all programmers live. See Kahan's
> 1997 John von Neumann lecture on The Baleful Effect of Computer
> Languages and Benchmarks upon Applied Mathematics, Physics, and
> Chemistry, available at
> http://http.cs.berkeley.edu/~wkahan/SIAMjvnl.ps.
...


Kahan does like to push the idea of using extended precision for
temporaries which, as you say, ignores the problem of how to specify
what is a temporary.


However where Kahan's creation (the 80x87 and its successors) really
fall down is that they make pure double precision impossible _and_
they make pure long double precision extremely difficult.


Writing pure double precision for the 80x87 is impossible because the
round_to_double flag doesn't quite work. It can introduce double
rounding, and it doesn't clamp the exponent. The exponent clamping can
be forced by writing to memory, but the double rounding is inevitable
(but rare?)


Simultaneously, the 80x87 makes it extremely difficult to write pure
extended precision math. Because most of the FPU instructions that
reference memory only support float or double precision, compiler
vendors have to write an entirely different code generator if they
want to support extended precision. Presumably that is why VisualC++
dropped support for long double some time ago.




So what are we left with? Who is happy?


1) The speed demons are moderately happy, because the latest
incarnations of the 80x87 are fairly fast. But they're not ecstatic,
because the bizarre tiny-stack architecture makes fast code beastly
complicated to write and debug, and still isn't as fast as it could
be.


2) Those who want predictable double precision results aren't happy
because the results they need are impossible to get all the time.
Although, with rounding set to double precision they probably do get
them 99.999% of the time - any other guesses?


3) Those who want full extended precision aren't happy because the
non-orthogonal architecture makes it perversely difficult to use this
feature.






So, on the upside, I don't think the unpredictable double precision
results happen that often, as long as the rounding mode is set to
double precision. On the downside, the benefits which are supposed to
justify the occasional unpredictable bits turn out to be illusory.


In short, if you want to design an FPU that has an ultra-fast or
ultra-precise mode you have to make sure it can be turned off
completely, for those who want predictability. And, you have to make
sure that turning it off is trivial - forcing compiler writers to do
anything more than set a bit is unacceptable - they won't do it.


--
Bruce Dawson, Cygnus Software Author of Fractal eXtreme for Win32
Get your 15 day trial copy of FX at: http://www.cygnus-software.com/
Write me at: comments@cygnus-software.com

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