J S. Moore. Piton: A verified assembly level language. Technical Report 22, Comp. Logic Inc, Austin, Texas, 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....command. This article is to relate Ken Thompson s example to compiler verification. The problem is known at least since Ken Thompson s lecture in 1984. However, in the programming languages and compiler community, L.M. Chirica and D.F. Martin ( 1] 1986) have been the first, and in 1988 J Moore [16] pointed out, that full compiler verification has not only to verify the transformation (mathematical mapping from source to target programs, compiling specification) but also the compiler implementation. Usually, implementation proceeds again in two steps: first, the compiler program is ....

....on syntactical code comparison. The second story is very closely related to Paul Curzon s work on compiler verification [2] The crucial difference is, that he uses and trusts a theorem prover (HOL) both to carry out the proofs and to execute the compiling specification, similar to the way J Moore [16, 17] and others [22] use ACL2 or its predecessor Nqthm in order to prove correctness of a compiler program which is executable within the prover. Now, that we modularized the compiler verification task into three steps, transformation verification, high level, and finally low level binary ....

J S. Moore. Piton: A verified assembly level language. Technical Report 22, Comp. Logic Inc, Austin, Texas, 1988.

....in part by NSF Grant MIP 9017499. most importantly, correctly) all the proof details. Automated reasoning systems have been successfully used to assist humans to check the correctness of some computer programs (see, for example, the survey paper [3] and the more recent, large scale efforts [7, 1]) We have recently used the automated reasoning system Nqthm [4] to define formally a mathematical specification for the widely used Motorola MC68020 microprocessor and to verify mechanically the correctness of machine code generated by high level programming language compilers for that ....

J Strother Moore. Piton: A verified assembly-level language. Technical Report CLI-22, Computational Logic, Inc., Austin, Tx, June 1988.

....attempt to give an overview. paper.tex; 23 02 1998; 16:05; p. 27 28 GERHARD SCHELLHORN AND WOLFGANG AHRENDT From the work on formal system supported verification of compilers we exemplarily want to mention the work with NQTHM on the formal verification of a compiler for an imperative language ((Moore, 1988), Young, 1988) This work is based on the notion of interpreter equivalence which is quite similar to our notion of equivalence of ASMs. It also contains a lot of references to related work. Of specific work on the formal verification of a Prolog compiler we are aware only of the parallel ....

Moore, J. (1988). PITON: A Verified Assembly Level Language. Technical report 22, Computational Logic Inc. available at the URL: http://www.cli.com.

....Work The planned work suggests several possible interesting detours. The floating point system model could actually be implemented. This entails writing a compiler for a portion of the logic that includes floating point operations. The target language of the compiler would probably 24 be Piton [16] so that the resulting code could be run on the verified stack. 3] The appeal of verifying a floating point program down to the level of hardware is very strong. It appears that backward error analysis of floating point programs [18] might benefit from algorithms that automate finding the ....

J Strother Moore. PITON: A Verified Assembly Level Language. Technical Report 22, Computational Logic, Inc., 1988.

....is fetched from the program segment according to the current value of the program counter and executed in the current state. The Piton instruction set, its semantics, its implementation on the FM8502 microprocessor, and the proof of the correctness of this implementation is fully described in [22] and summarized in [21] 11 Chapter 4 THE CORRECTNESS OF THE MICRO GYPSY CODE GENERATOR The translator from Micro Gypsy to Piton takes a Micro Gypsy execution environment (including the program) and creates a Piton state. This is implemented as a function MAP DOWN in the Boyer Moore logic. The ....

J S. Moore. PITON: A Verified Assembly Level Language. Tech. Rept. CLI-22, Computational Logic, Inc., June, 1988. 32

....describes a compiler for the NQTHM logic and a mechanically checked proof of its correctness. The NQTHM logic defines an applicative programming language very similar to McCarthy s pure Lisp [McCarthy 62] The compiler compiles programs in the NQTHM logic into the Piton assembly level language [Moore 88] The correctness of the compiler is proven by showing that the result of executing the Piton code is the same as produced by the NQTHM interpreter V C . A completed prototype for the compiler is discussed. The prototype includes 10 of the 61 predefined functions in the NQTHM logic. Design of a ....

....programming language similar to pure Lisp and the mechanically checked proof of its correctness. The Boyer Moore logic (hereafter referred to as the Logic) defines an applicative programming language similar to pure Lisp. The compiler produces code in the high level assembly language Piton [Moore 88] Since the Logic includes CONS, the implementation must dynamically allocate storage, and inclusion of a garbage collector is desirable. Among the significant achievements of this project are the following: The compiler is proven to correctly implement one abstract data type (e.g. CONS) on top ....

[Article contains additional citation context not shown here]

J Strother Moore. PITON: A Verified Assembly Level Language. Technical Report 22, Computational Logic, Inc., 1988.

.... programs, it behooves us to look carefully into research in mechanical program verification [9, 10, 18] The work most relevant to this dissertation seems to be the research on formalizing the semantics of individual von Neumann machines such as a microprocessor [11] an assembly language machine [95], a Micro Gypsy (a Pascal like language) machine [122] and various other machines [5] in the Boyer Moore logic for the purpose of verifying programs and systems mechanically. The semantics of these various machines have been formalized by defining Lisp interpreters for various programming ....

J Strother Moore. Piton: A verified assembly-level language. Technical Report CLI-22, Computational Logic, Inc., Austin, Tx, June 1988.

....We also had a small amount of input into the design of Piton; seven Piton instructions were added to accommodate the MicroGypsy project. 5 1. 4 The Boyer Moore Kaufmann Proof Checker The implementation and specification of the Micro Gypsy compiler were written in the Boyer Moore logic [BoyerMoore 88] Proofs were carried out using the Boyer Moore proof checker enhanced with an interactive interface by Matt Kaufmann [Kaufmann 88] A description of the logic and the proof checker is contained in Appendix A. The choice of this proof environment (rather than, say, the Gypsy Verification ....

....to define Map Up without reference to the high level state. For example, the Map Down function may map all high level data values into bit vectors. We cannot map these values back into a high level context without some type information for the inverse mapping. This is the case for the Piton proof [Moore 88] as well as for our code generator proof. This issue is discussed further below. 11 P S, 2) P, S E SL Int ( P, S ) Map Up (Int (Map Down ( P, S ) SL TL This gives us the commutative diagram in figure 2 2. Notice that if we can show that SL initial SL final TL initial TL final ....

[Article contains additional citation context not shown here]

J S. Moore. PITON: A Verified Assembly Level Language. Technical Report CLI-22, CLInc, June, 1988.

....from school. Results of laborious algorithms like dividing or equations solving are to be double checked by afterward proofs. The ways of acting of T UV and BSI are responsible and right w. r. t. momentary engineering standard. Due to L. M. Chirica, D. F. Martin [CM86] and J S. Moore [Moo88, Moo96] full realistic compiler correctness is not only translation (specification) correctness, i.e. correctness of a mathematical mapping from source to target code, but also correctness of implementation of translators for realistic programming languages, implementation down in binary machine ....

....verification. Clear: Translation verification for trans S T has to be done beforehand, but is not at all sufficient for full translator correctness. Correct T diagrams can be syntactically composed by ; like programs. 2.4 Steps towards Correctly Implemented Translators J S. Moore [Moo88] has formulated the necessary steps towards correct implementation of a translator tH . If translators shall be trusted even in safety critical applications trustworthily proved correctness must hold also and especially if tH is implemented in binary real machine code H. First step: Source ....

[Article contains additional citation context not shown here]

J S. Moore. Piton: A verified assembly level language. Technical Report 22, Comp. Logic Inc, Austin, Texas, 1988.

....binary machine code executable of the compiler is possible and feasible. In order to guarantee full compiler correctness, we have to verify carefully both, the compiling specification and the compiler implementation. Chirica and Martin [1] have first described this explicitely. In 1988, J Moore [19] pointed out that full compiler verification has to verify the compiler implementation as well. He verified a compiler program, written in Boyer Moore Lisp, but not its binary implementation. Unfortunately, for the final compiler executable, the literature gives no sufficient solution so far. ....

....the double check proof work. 4 Conclusions and Related Work The idea to separate compiling specification correctness from compiler implementation correctness and to prove both of them in order to gain full correctness has first been described explicitly by Chirica and Martin [1] J S. Moore [19, 20] also distinguishes these tasks. He uses the Boyer Moore prover nqthm to prove the correctness of a compilation function from Piton into FM8501 Code. More recently, the VLisp project reports [26, 11] also express the necessity of proving the compiler implementation correct. In the VLisp and in the ....

J S. Moore. Piton: A verified assembly level language. Technical Report 22, Comp. Logic Inc, Austin, Texas, 1988.

....refining the compiling specification into a program formulated in high level compiler implementation language, the compiler program itself has to be transformed into a binary machine program. An implementation correctness proof is necessary. This fact has first been severely stressed by J Moore [13]. Unfortunately, the literature on compiler verification gives no sufficient solution so far. No fully reliable realistic compiler implementation is available, since this agenda has not been completely worked out for any existing compiler or programming language implementation. Compilers and, ....

....the Boyer Moore prover is used to construct and verify a stack of components (CLInc stack) covering the compilation of the high level imperative language Micro Gypsy down to the hardware processor FM8502. This imperative language is first compiled to assembler code [18] and further to machine code [13]. Compiler and assembler are specified and verified with respect to source and target language semantics. In [13] J S. Moore formulated the necessity of also proving the implementation correct. However, even in the CLInc project this gap has not been closed so far. The Boyer Moore prover, both ....

[Article contains additional citation context not shown here]

J S. Moore. Piton: A verified assembly level language. Technical Report 22, Comp. Logic Inc, Austin, Texas, 1988.

....of the correctness of the compiler implementation. It is answered by the Compiler Verification process. Only few publications about compiler correctness mention the correctness of a compiler implementation in machine code at all. Those that do, explicitly exclude this step from their research [11, 5]. But full compiler correctness (and with it the correctness of all of the programs it will generate) crucially depends on its correct implementation in machine code Within Verifix, we develop methods for compiler implementation verification [4] and the rest of this article explains its basic ....

J S. Moore. Piton: A verified assembly level language. Technical Report 22, Comp. Logic Inc, Austin, Texas, 1988.

....the double check proof work. 6 Conclusion and Related Work The idea to separate compiling specification correctness from compiler implementation correctness and to prove both of them in order to gain full correctness has first been described explicitly by Chirica and Martin [1] J S. Moore [17, 18] also distinguishes these tasks. He uses the Boyer Moore prover nqthm to prove the correctness of a compilation function from Piton into FM8501 Code. More recently, the VLisp project reports [22, 10] also express the necessity of proving the compiler implementation correct. In the VLisp and in the ....

J S. Moore. Piton: A verified assembly level language. Technical Report 22, Comp. Logic Inc, Austin, Texas, 1988.

....compiler for a subset of the Nqthm logic and a mechanically checked proof of its correctness is described. The Nqthm logic defines an applicative programming language very similar to McCarthy s pure Lisp[20] The compiler compiles programs in the Nqthm logic into the Piton assembly level language [23]. The correctness of the compiler is proven by showing that the result of executing the Piton code is the same as produced by the Nqthm interpreter V C . The Nqthm logic defines several different abstract data types, or shells, as they are called in Nqthm. The user can also define additional ....

....a formal statement of its correctness and the mechanically checked proof of that statement. The Boyer Moore logic (hereafter referred to simply as the Logic) defines an applicative programming language similar to pure Lisp. The compiler produces code in the high level assembly language Piton [23]. The proof has been broken down into steps in anticipation of its eventual extension to handle all of the Logic. The compiler for the full Logic is described and how the mechanically checked proof for the prototype can be extended is explained. The Logic includes functions to construct new ....

[Article contains additional citation context not shown here]

J Strother Moore. Piton: A verified assembly level language. Technical Report 22, Computational Logic, Inc., 1988.

....steps. These large transformations, which embody a procedural analysis of the source code, seem to require the freedom of the denotational semantics. We would consider it a difficult challenge to verify the PreScheme Front End, for instance, using the operational style of the Piton compiler proof [20]. 5.2. Disadvantages of the Denotational Approach There are however some serious limitations to the denotational approach in the traditional form embodied in the official Scheme semantics. At the prosaic end of this spectrum, there is of course the fact that in some cases one must reason about ....

J Strother Moore. Piton: A verified assembly-level language. Technical Report 22, Computational Logic, Inc., Austin, Texas, 1988.

....machine instructions. These were mostly minor in nature (registers not being saved across routine calls, etc. and were below the grain of the proof. Extending the proof to reach this level would require an extremely detailed model of the behavior of the machine and operating system (see, e.g. [17, 4]) In practice, however, the stored program machine was at a sufficiently low level that implementation of the primitives was easy. The method of formalizing storage layout relations seems to be flexible enough to model standard representation strategies. More of these are presented in [8, 31] ....

J Strother Moore. Piton: A verified assembly-level language. Technical Report 22, Computational Logic, Inc., Austin, Texas, 1988.

....the double check proof work. 6 Conclusions and Related Work The idea to separate compiling specification correctness from compiler implementation correctness and to prove both of them in order to gain full correctness has first been described explicitly by Chirica and Martin [1] J S. Moore [16, 17] also distinguishes these tasks. He uses the Boyer Moore prover nqthm to prove the correctness of a compilation function from Piton into FM8501 Code. More recently, the VLisp project reports [21, 9] also express the necessity of proving the compiler implementation correct. In the VLisp and in the ....

J S. Moore. Piton: A verified assembly level language. Technical Report 22, Comp. Logic Inc, Austin, Texas, 1988.

....translated to LSI Logic s Netlist Description Language and implemented by LSI Logic, Inc. as a CMOS gate array. Rigorous testing has not uncovered any situation where the manufactured device fails to meet its specification. The FM9001 also serves as the target for the verified assembler, Piton [42], which in turn serves as the target of the verified Gypsy compiler [49] This document presents the details of the FM9001 development, its specification, and its verification. 1 RESULTS We believe that a significant result of the FM9001 microprocessor study is that we have shown it is ....

....of the A operand, and all side effects to the A operand register (pre decrement or post increment) are completed before the computation of the effective address of the B operand. 2 This feature was added to the FM8502 processor to simplify the proofs of correctness of the PITON interpreter [42]. We retained this feature in the FM9001. REGB MODEB V N Z C STORE CC OP CODE UNUSED REGA MODEA UNUSED 28 24 20 19 18 17 16 15 14 10 9 0 31 27 23 8 13 6 5 4 3 0 TWO ADDRESS MODE 0 IMMEDIATE 1 REGB MODEB V N Z C STORE CC OP CODE UNUSED 28 24 20 19 18 17 16 15 14 10 9 31 27 23 8 13 IMMEDIATE ....

J S. Moore. Piton: A Verified Assembly Level Language. Technical Report 22, Computational Logic, Inc., 1717 West Sixth Street, Suite 290 Austin, TX 78703, 1988.

....and mixed verification environments for a hardware design language, a machine code, an assembly language, and Micro Gypsy. Indeed, we have used these verification environments independently of the short stack to verify properties of programs written in the individual languages. See for example [5]. We have also derived performance bounds on high level programs in the sense that the proofs give us a constructive characterization of the number of microcode cycles that must be executed to carry out a 4 high level computation. These clock functions are, of course, hierarchically developed ....

.... suitable to proving the reliability of communication protocols for independently clocked processors [8] Turing machines [9] Lambda calculus [10] a simple but usable machine code [11] a large part of the machine code for the MC68020 [12] a stack based assembly language [5], several high level languages including Micro Gypsy [13] Middle Gypsy [14] the Nqthm logic itself [2] and a small subset of Ada [15] a home grown separation kernel (implementing multi processing on a uniprocessor) 16] 6 . a requirements model for the Mach micro kernel, and . the ....

J S. Moore, "Piton: A Verified Assembly Level Language", Tech. report 22, Computational Logic, Inc., 1717 West Sixth Street, Suite 290 Austin, TX 78703, 1988.

....to represent our specifications. This allows the comparison of our Boolean circuits to abstract specifications containing, for example, integers, as well as comparing Boolean circuits to other Boolean circuits. Both ALU specifications are described as functions in the Boyer Moore logic [Boyer Moore 88] The proof time to verify the equivalence of the two n bit Boolean ALU specifications takes constant time. When a particular sized ALU is desired, then the ALU specifications functions are expanded (in linear time) into graphs of gates suitable for implementation. The remainder of this paper ....

....for all word sizes. This type of verification requires induction, which is not found in Boolean decision procedures. To demonstrate our approach we present the verification of two selector implementations by induction. 2. 2 The Boyer Moore Logic and Theorem Prover The Boyer Moore logic [Boyer Moore 88] is a quantifier free, first order predicate calculus with equality. Logic formulas are written in a prefix style, Lisp like notation. Included with the logic are several built in data types: Booleans, natural numbers, lists, literal atoms, and integers. The Boyer Moore logic is unusual in that ....

J S. Moore. Piton: A Verified Assembly Level Language. Technical Report 22, Computational Logic, Inc., 1717 West Sixth Street, Suite 290 Austin, TX 78703, 1988.

....a runtime system that does not provide a garbage collector. Flatau, Fla92] flatau app f.events ) this event file is analogous to the immediately preceding one, but corresponds to Appendix F of [Fla92] and deals with a runtime system including a reference counting garbage collector. Moore, [Moo88], fm9001 piton big add.events ) a proof of the correctness of a Piton program for adding arbitrarily long numbers in base 2 32 (Brock and Hunt, HB92] fm9001 piton fm9001.events ) formalizations of a netlist description language, the machine code for the 32 bit FM9001 microprocessor, the ....

....a proof that a given 300 line Piton program plays the game of Nim optimally; the program is also shown to be loadable onto the FM9001 (satisfying the requirements of the correctness theorem for Piton) bounds on the program s execution time have been proved using Pc Nqthm. Moore, [Moo88], fm9001 piton piton.events ) the definition of the Piton assembly language, its implementation on the FM9001 via a compiler, assembler and linker, and a proof of the correctness of the FM9001 implementation (Boyer and Moore, BM81] fortran vcg fortran.events ) the same file as basic fortran, ....

J S. Moore. Piton: A verified assembly-level language. Technical Report CLI-22, Computational Logic, Inc., Austin, Tx, June 1988.

....for which we have a verified gate level design. By choosing such a lower level machine we forced the language implementation to face issues (such as link assembling) not generally faced in previously reported work on verified implementations. This paper is a brief summary of a much longer report ( [12]) in which we . formally define an assembly level programming language, demonstrate its utility for programming and for verification purposes, implement it on the FM8502 microprocessor via a compiler and link assembler written as functions in the computational logic of Boyer and Moore [1, ....

....proof of the correctness of the implementation. We believe that this is the most complete and comprehensive language implementation proof to date. 2 In this paper we briefly touch on each of the issues above. Space prevents a thorough treatment. However, the curious reader is urged to see [12] where the details are spelled out both formally and informally. The purpose of the present paper is to give the reader enough information to determine the accuracy of our claim that we have verified a compiler and link assembler or more precisely a cross compiler and cross link assembler ....

[Article contains additional citation context not shown here]

J S. Moore. Piton: A Verified Assembly Level Language. Tech. Rept. 22, Computational Logic, Inc., 1717 West Sixth Street, Suite 290 Austin, TX 78703, 1988.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC