extended precision hazards

[Jerome T. Coonen]

David Hough comments:

> /* On a machine with IEEE extended-precision registers, it is
>  * necessary to specify double-precision (53-bit) rounding precision
>  * before invoking strtod or dtoa...
>  */
> 
> An all-too-familiar warning.    The point relative to the ongoing Java
> discussions in this mailing list is not that C compilers and C programs
> can't be written to handle IEEE 754 extended precision correctly and
> consistently, but that after 15 years they still usually aren't...

There is another point relative to ongoing Java discussions.  One reason
for the abysmal state of C compilers on some extended-based platforms is
the lack of guidance from the C standards body, a situation that would
change considerably with the adoption of C9x.

Unfortunately, history has a chance to repeat itself.  By ignoring
the performance issues of the vast number of platforms with extended
extended registers or fused multiply-add operations, the Java spec
invites nonconformance from vendors who choose not to suffer 1.5X
to 10X performance degradation in numerical codes in order to match
the results of less capable architectures.  At worst, that
nonconformance will be as random and capricious as has the
situation been with C.

One alternative is to pursue -- in advance -- a Java design
encouraging robust, high-performance, portable code across all
platforms.

-Jerome Coonen