One way to ensure correctness of the inference performed by computer theorem provers is to force all proofs to be done step by step in a simple, more or less traditional, deductive system. Using techniques pioneered in Edinburgh LCF, this can be made palatable. However, some believe such an approach will never be efficient enough for large, complex proofs. One alternative, commonly called reflection, is to analyze proofs using a second layer of logic, a metalogic, and so justify abbreviating or simplifying proofs, making the kinds of shortcuts humans often do or appealing to specialized decision algorithms. In this paper we contrast the fully-expansive LCF approach with the use of reflection. We put forward arguments to suggest that the inadequacy of the LCF approach has not been adequately demonstrated, and neither has the practical utility of reflection (notwithstanding its undoubted intellectual interest). The LCF system with which we are most concerned is the HOL proof ...

This thesis describes substantial enhancements that were made to the software tools in the Nuprl system that are used to interactively guide the production of formal proofs. Over 20,000 lines of code were written for these tools. Also, a corpus of formal mathematics was created that consists of roughly 500 definitions and 1300 theorems. Much of this material is of a foundational nature and supports all current work in Nuprl. This thesis concentrates on describing the half of this corpus that is concerned with abstract algebra and that covers topics central to the mathematics of the co...

. Starting from a denotational and a term-rewriting based operational semantics (an interpreter) for a small functional language, we present a correctness proof of the interpreter w.r.t. the denotational semantics. The complete proof has been formalized in the logic LCF and checked with the theorem prover Isabelle. Based on this proof, conclusions for mechanical theorem proving in general are drawn. 1 Introduction Compiler and interpreter verification is a key component in the correctness argument for any software system written in a high-level language. Otherwise the carefully verified high-level programs might be compiled or interpreted incorrectly. Proving the correctness of machine oriented programs [3] instead may be inevitable for some applications, but is methodologically a step backwards. Verification of compilers and interpreters is also challenging from a theoretical point of view because complex semantical questions are involved [5, 6]. These comprise the formalizati...

Specification of Compiler Correctness 1.3 Compiler Specifications A compiler (the code generation part at least) must produce object code whose meaning corresponds to that of the source program. An abstract compiler specification can be given in terms of the source and object language semantics. Informally, a compiler will be correct if the meaning of every source program is related to the meaning of the object code resulting from compiling it. More formally, a compiler must fulfil an abstract specification of the form below. AbstractCompilerSpec compiler = 8p. Compare (SourceSemantics p) (ObjectSemantics (compiler p)) SourceSemantics gives the semantics of the source language, ObjectSemantics gives the semantics of the target language and Compare relates semantics of the two forms. The argument compiler is a compiler from the source language to the target language. This form of specification is illustrated in Figure 1.2. Many different object programs will be suitable as an implem...

Abstract: This paper overviews the application of formal verification techniques to hardware in general, and to floating-point hardware in particular. A specific challenge is to connect the usual mathematical view of continuous arithmetic operations with the discrete world, in a credible and verifiable way.

this report includes an overview of the research and the final deliverables funded on the SRI project. Some of these build on results of the Computer Laboratory project and the contributions of Mr. John Harrison, Dr. Wai Wong and Dr. Joakim von Wright of the University of Cambridge Computer Laboratory are gratefully acknowledged. Research tasks

Program verification is normally performed on source code. However, it is the object code which is executed and so which ultimately must be correct. The compiler used to produce the object code must not introduce bugs. The majority of the compiler correctness literature is concerned with the verification of compiler specifications rather than executable implementations. We discuss different ways that verified specifications can be used to obtain implementations with varying degrees of security. In particular, we describe how a specification can be executed by proof. We discuss how this method can be used in conjunction with an insecure production compiler so as to retain security without slowing the development cycle of application programs. A verified implementation of a compiler in a high-level language is not sufficient to obtain correct object code. The compiler must itself be compiled into a low-level language before it can be executed. At first sight it appears we need an already...

Starting from a denotational and a term-rewriting based operational semantics (an interpreter) for a small functional language, we present a correctness proof of the interpreter w.r.t. the denotational semantics.

We present an analysis of a protocol developed by Philips to connect several components of an audio-system. The veri cation of the protocol is carried out using the timed I/O-automata model of Lynch andVaandrager. The veri cation has been partially proof-checked with the interactive proof construction program Coq. The proof-checking revealed an error in the correctness proof (not in the protocol!). 1