And "Albert D. Cahalan" writes:
- 2. Extra precision when it comes free. The precision control is set
- to 80-bit and the compiler tries to keep values in registers.
- This is usually the more useful behavior, and it performs better.
Even better is for gcc to spill intermediate results to 80 bits.
Unfortunately, these 80 bits have to be expanded to 128 for
alignment, and this eats cache. IIRC, this has been discussed
many times by gcc developers. I don't recall the final verdict.
The original intent with the 8087 was that the compiler and/or
OS could transparently extend the stack into memory, but one
necessary feature was left out until the 80387. By that point,
it was too late. And then came caches...
- What you are suggesting is a gross hybrid. You claim it has something
- to do with IEEE, but it doesn't handle 32-bit math correctly. Your
- proposal is NOT true IEEE math.
Note that getting what some people want to call `true' IEEE 754
arithmetic on an x86 is frightfully tricky. Changing the precision
does not shorten the exponent field, and that can have, um, fun
effects on and around under/overflow. The mantissa and exponent
lengths were chosen carefully to protect against those effects in
What Linux does presently on x86 is as right as right can be on
this platform. Compare with what MS's compilers do (die when you
run out of the fp stack slots, telling users to simplify the
expressions in the source code) and be happy. The *BSD choice is
valid by some lines of thought, but it also denies people the happy
accident of computing with more precision and range than they thought
they needed. Overall, computing with x86 double-extended is a good
thing so long as you don't introduce multiple roundings. That's a
compiler issue, not a kernel one.
Historical note: According to one of the x87 designers, this all
boils down to the simple fact that there's no time when a pair of
collaborators in California and Israel can be both awake and lucid
enough to explain things well over a noisy telephone line. Amazing
that it really wasn't long ago. And if anyone's really interested,
as some of Dr. Kahan's older papers are slowly converted and added.
They give a great deal of insight into the choices that eventually
became the accepted IEEE 754 standard.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 07 2001 - 21:00:15 EST