32bit vs. 64bit

Jaroslav Hajek highegg at gmail.com
Sat Mar 14 17:02:02 CDT 2009


On Sat, Mar 14, 2009 at 9:56 PM, Jason Riedy <jason at acm.org> wrote:
> 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.

OK, it seems I have some concepts confused. I always thought that
"guard bits" means the implicit 80-bit reals used in x86 processors.
In any case, I was referring to the fact that on x86_64, adding eps/5
10 times to 1 does produce 1, even if the values are declared
"register". I think this worked on 32-bit machines.

> 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.
>

Interesting.

>> 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.
>

What? They use ATLAS?

thanks


-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



More information about the Bug-octave mailing list