Related articles |
---|
[6 earlier articles] |
Re: Compiler Correctness torbenm@app-1.diku.dk (2006-02-11) |
Re: Compiler Correctness henry@spsystems.net (2006-02-11) |
Re: Compiler Correctness Sid.Touati@inria.fr (Sid Touati) (2006-02-11) |
Re: Compiler Correctness haberg@math.su.se (2006-02-11) |
Re: Compiler Correctness haberg@math.su.se (2006-02-11) |
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) |
[2 later articles] |
From: | Xavier Leroy <Xavier.Leroy@inria.fr> |
Newsgroups: | comp.compilers |
Date: | 12 Feb 2006 10:59:55 -0500 |
Organization: | INRIA Rocquencourt, projet Cristal |
References: | 06-02-053 06-02-061 06-02-078 |
Keywords: | theory, debug |
Posted-Date: | 12 Feb 2006 10:59:55 EST |
Sid Touati <Sid.Touati@inria.fr> writes:
> I didn't read its last POPL article yet, but I remembered one of his
> talks about this subject (certifying a simple compiler). At that time, I
> noticed the following hole in their proof. [...]
> Such code optimization has been proved correct by coq, but an
> informal assumption has been forgotten. Indeed, the machine
> executing the compiler may be distinct from the machine executing
> the final generated code. This is the case of cross compilers for
> example.
There is no hole of that kind in my compiler proof. The compiler
implements its own 32-bit integer arithmetic, as Coq functions that
are proved to satisfy all the arithmetic and logic properties that the
compiler optimizations rely on (associativity, distributivity,
multiplication by power of 2 is a left shift, etc). This arithmetic
is completely independent of that of the processor executing the
compiler.
These arithmetic operations are used both during compilation (e.g. the
constant propagation phase you mention) and in the formal semantics
for the target processor. That's what ensures that constant
propagation preserves semantics. If const.prop. were to use a
different arithmetic than the target processor, Coq would of course
reject the proof.
Now, you can have doubts that the arithmetic used by the compiler
matches that implemented by the target compiler. This comes back to
the issue raised by other posters in this thread, namely that the
formal semantics for the source language and the target processors
have not been formally proved correct, but only validated informally
by careful reading and by testing. (This is still much easier than
validating a whole compiler using these informal approaches.)
Formal validation of the semantics is possible, e.g. for the target
processor by relating it to the formal models used by processor
manufacturers to verify their chips. Unfortunately, such formal
models of hardware are generally trade secrets, so this is beyond the
scope of my compiler certification project.
- Xavier Leroy
--
Valid e-mail address (without the underscores): Xavier.Leroy@i_n_r_i_a.f_r
Home page: http://pauillac.inria.fr/~xleroy/
Return to the
comp.compilers page.
Search the
comp.compilers archives again.