22 Sep 1998 14:45:35 -0400

Related articles |
---|

Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-22) |

Re: floating point precision discussion jacob@jacob.remcomp.fr (1998-09-22) |

Re: floating point precision discussion chrisd@reservoir.com (Chris Dodd) (1998-09-22) |

From: | jacob@jacob.remcomp.fr (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 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]

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.