This is the mail archive of the
mailing list for the GCC project.
Re: Kahan's Floating Point Test
- To: moshier at moshier dot ne dot mediaone dot net, mprice at atl dot imco dot com
- Subject: Re: Kahan's Floating Point Test
- From: dewar at gnat dot com
- Date: Wed, 30 May 2001 14:25:23 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org
<<The floating point hardware on x86 is not IEEE compliant. You can
come close by setting the rounding precision of the fpu to the desired
working precision of the numbers. See /usr/include/fpu_control.h
on linux for the functions or macros to do that.
Of course the floating-point hardware on the x86 is IEEE compliant. Indeed
ANY hardware is IEEE compliant, since IEEE is not a hardware but a system
standard (i.e. a system which used an IEEE simulator on an IBM 360 wouldbe
compliant). What we usually mean by saying that hardware is IEEE compliant
is that all the operations in the standard map into the hardware in a
reasonably direct manner. We do NOT require that there is a single instruction
for every operation (indeed some of the operations like binary to decimal
conversion are typically expected to be done in software).
Most certainly the x86 is IEEE compliant in any reasonable definition
of the term. yes, you have to watch out for the effects of extra
precision and if necessary to extra loads/stores, and indeed everyone
should know about this (similar issued occur in the power family of
architectures, but they are not so severe there).
Many architectures have places where you have to improvise a bit to
get arbitrary IEEE results. For example, many architectures expect
denormals to be handled by software, but this does not make them
non-IEEE compliant. On the other hand, the behavior of the MIPS R10K in
flushing to zero is severe, and it is reasonable to say that this processor
is not IEEE compliant, since you can't even map an add instruction into
hardware at all.