Re: AMD compilers tol use REAL(16) syntax?
From: Dr Chaos (mbkennelSPAMBEGONE_at_NOSPAMyahoo.com)
Date: Sat, 11 Oct 2003 21:36:35 +0000 (UTC)
On Sat, 11 Oct 2003 17:40:20 GMT, Norbert Juffa <email@example.com> wrote:
> "David Frank" <firstname.lastname@example.org> wrote in message news:Rqwhb.88126$eS5.email@example.com...
>> The 68bit fraction and 18 bit exponent of the AMD opteron leads
>> into the question how does a Fortran compiler command this "90-bit"
>> Since AMD has challenged my BYTES RULE computer model universe with a
>> 90-bit format, doesnt this throw a monkey-wrench into my contention?
>> Not to worry, if the compiler writers are smart they will just refer
>> it as REAL(16) since the new format resides in 128 bit registers and
>> MUST be fetched/stored with at least 16byte memory transfers else it
>> will be terribly inefficient.
> There is no user visible 90-bit number format on AMD CPUs. It's merely
> an internal format, and the "90 bit" designation seems to include the
> tag bits in the count. 80-bit extended precision format is the widest
> user visible format, and it is only available when using the classic
> "x87" FPU, not through SSE2. From what I read, AMD emphasises SSE2 for
> 64-bit environments which makes sense as it is true double precision
> (avoids many pitfalls due to wider internal precision/exponent ranges),
> supports SIMD computations, and has twice the number of FPU registers
> available compared to "x87" (16 vs 8).
> The 68 mantissa bits are there to support the computation of extended
> precision transcendental functions with < 1 ulp accuracy (note that
> the trig functions sin, cos, tan use a 68-bit machine PI in argument
> reduction). The 18-bit exponent range avoids overflows in intermediate
> computations performed internally to the chip.
It would be nice if the new chips had some mode which essentially
made computations identical to, say Sun SPARCstations, and we
can stop worrying about this insane issue, and get back to physics
and fundamental numerical stability.