Re: Compiler Correctness (Henry Spencer)
17 Feb 2006 00:06:16 -0500

          From comp.compilers

Related articles
[11 earlier articles]
Re: Compiler Correctness (2006-02-11)
Re: Compiler Correctness (Xavier Leroy) (2006-02-12)
Re: Compiler Correctness (Hans-Peter Diettrich) (2006-02-14)
Re: Compiler Correctness (Marco van de Voort) (2006-02-14)
Re: Compiler Correctness (Hans-Peter Diettrich) (2006-02-14)
Re: Compiler Correctness (2006-02-17)
Re: Compiler Correctness (2006-02-17)
Re: Compiler Correctness (Sid Touati) (2006-02-17)
Re: Compiler Correctness (glen herrmannsfeldt) (2006-02-17)
Re: Compiler Correctness (=?iso-8859-1?Q?Ingo_St=FCrmer?=) (2006-04-27)
| List of all articles for this month |

From: (Henry Spencer)
Newsgroups: comp.compilers
Date: 17 Feb 2006 00:06:16 -0500
Organization: SP Systems, Toronto, Canada
References: 06-02-053 06-02-078 06-02-093 06-02-107
Keywords: arithmetic
Posted-Date: 17 Feb 2006 00:06:16 EST

Hans-Peter Diettrich <> wrote:
>Ambiguities also can arise from different models or precision, as
>implemented in specific FPU hardware. Doesn't this imply that a correct
>compiler must emulate all floating point operations, so that the output
>does not depend on the host machine of the compiler?

Not *necessarily*, although (as I said in a previous message) that may be
a sensible thing to do on general principles.

IEEE floating point, in particular, is sufficiently tightly specified and
sufficiently widely used that a careful cross-compiler running on an IEEE
machine could mostly use its host floating-point hardware to emulate the
floating point of many target machines. (It might have to resort to
software emulation in some tricky areas.)

>The operation of the Intel coprocessor (x87) is configurable, and this
>configuration can be changed at runtime.

That's true of IEEE FPUs in general, not just the x86 one.

>In this case a "correct" compiler has to assure that, after every
>call to external code, the FPU configuration is restored to the
>expected state.

Indeed so. Modern language definitions increasingly are specifying the
details of where FPU state changes, which state changes propagate into and
out of a called routine, etc. With an older language spec, there's room
for implementer judgement about how things should work, but that's no
different from many other areas.
-- is temporarily off the air; | Henry Spencer
mail to henry at instead. |

Post a followup to this message

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