Re: floating point precision discussion

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 48.23.51.44
93430 Villetaneuse Fax 01 48.23.95.39
France
[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]




--

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