Re: Compiler Correctness

henry@spsystems.net (Henry Spencer)
17 Feb 2006 00:06:16 -0500

          From comp.compilers

Related articles
[11 earlier articles]
Re: Compiler Correctness henry@spsystems.net (2006-02-11)
Re: Compiler Correctness Xavier.Leroy@inria.fr (Xavier Leroy) (2006-02-12)
Re: Compiler Correctness DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-02-14)
Re: Compiler Correctness marcov@stack.nl (Marco van de Voort) (2006-02-14)
Re: Compiler Correctness DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-02-14)
Re: Compiler Correctness henry@spsystems.net (2006-02-17)
Re: Compiler Correctness henry@spsystems.net (2006-02-17)
Re: Compiler Correctness Sid.Touati@inria.fr (Sid Touati) (2006-02-17)
Re: Compiler Correctness gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-02-17)
Re: Compiler Correctness ingo.stuermer@gmx.de (=?iso-8859-1?Q?Ingo_St=FCrmer?=) (2006-04-27)
| List of all articles for this month |

From: henry@spsystems.net (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

Hans-Peter Diettrich <DrDiettrich@compuserve.de> 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.
--
spsystems.net is temporarily off the air; | Henry Spencer
mail to henry at zoo.utoronto.ca instead. | henry@spsystems.net


Post a followup to this message

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