Re: floating point precision discussion (Jacob Navia)
22 Sep 1998 14:45:35 -0400

          From comp.compilers

Related articles
Re: inlining + optimization = nuisance bugs (Luddy Harrison) (1998-09-22)
Re: floating point precision discussion (1998-09-22)
Re: floating point precision discussion (Chris Dodd) (1998-09-22)
| List of all articles for this month |

From: (Jacob Navia)
Newsgroups: comp.compilers
Date: 22 Sep 1998 14:45:35 -0400
Organization: Compilers Central
References: 98-09-093
Keywords: arithmetic

Luddy harrison wrote:
> My reading of the programming manual for the PowerPC is that the
> internal registers that hold the intermediate result for a
> multiply-add instruction have extended precision. If this is true,
> and if it is true that occasional use of extended precision is
> 'wrong', then there is virtually no circumstance under which a
> compiler can correctly generate the PowerPC fmadd and fmsub
> instructions, for example. This strikes me as a very severe
> interpretation of floating point semantics.

I would say the same for the x86 architectures: The x86 stores all
floating point in an internal 80 bit format. Conversion from this
format to the normal floating point format (64 bits) is done at
floating point stores ONLY. If we would do all operations in the
standard 64 bit precision it would be IMPOSSIBLE to keep intermediate
results in registers, and all compilers would have to issue memory
loads/stores at EACH operation...

The issue becomes even more complex if we use built in functions of
the x86 processor like sqrt or sin, that are internally done in 80 bit
precision. This operations are the result of many extended precision
operations... and they could conceivable differ from a sqrt calculated
by software using 64 bit precision for each operation.
Jacob Navia Logiciels/Informatique
41 rue Maurice Ravel Tel 01
93430 Villetaneuse Fax 01
[Well, actually, there's are flag bits that lets you set the internal
precision of the x86 to 32, 64, or 80 bits, so the forced store
argument is a red herring. But remember, the problem isn't that we
don't want all the precision we can get, it's that inconsistent
precision gives you wrong answers. I can live with just about any set
of precision rules so long as they're documented and deterministic,
and don't depend on unpredictable compiler decisions about register
spilling. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.