32bit vs. 64bit

[Jason Riedy]

And Jaroslav Hajek writes:
> Yes, and as Sergei noted, x86_64 actually doesn't use guard bits,
> because it supports quadruple precision (128-bit fp).

FYI, those are orthogonal.  And both statements are a little
incorrect.

A guard bit prevents bizarre cancellation errors during
subtraction.  Every major CPU since the *old* Cray vector boxes
has guard bits; the cost is tiny in respect to the support hell
for not having guard bits.  There are two other bits, round and
sticky, that ensure correct rounding.  They exist only in the
arithmetic path and are not stored in a register.

Also, x86-64 does not support quad precision in hardware.  The
architecture defines 128-bit alignment for the 80-bit double-
extended values for the x87 FPU[1].  The double-extended x87 still
is available.  In gcc, long double maps to the x87, or you can
use -mfpmath=387 or -mfpmath=387,sse to use the x87 unit for
doubles.

Conversely, -mfpmath=sse in 32-bit mode would ensure doubles live
in the strictly 64-bit-precise SSE unit.  The downside is the
code will only run on machines with SSE units.

> That's interesting, given that they certainly rely on external
> libraries (ACML or MKL, SuiteSparse...). I wonder how they make these
> to be "bit exact".

Oh, and you should hear them whine about ATLAS, etc.

And Michael D. Godfrey writes:
> In any case, rounding error analysis  get less attention these days
> than it deserves.

Please complain to the ACM and have them reinstate it in their
course suggestions.  Currently, all explicit discussion of
floating-point they recommend is one session in the hardware /
assembler / architecture class.  Having discussion of
floating-point somewhere in the "standard" curriculum might help,
at least a little.  Yes, I'm being hopeful.

Jason

Footnotes: 
[1]  Alas, this isn't enough to support quad in the future,
either.  The 80-bit format has an explicit leading bit, while
"true" (and now IEEE-754) quad has an *implicit* leading bit.