I present aninterpretation of machine language programs as boolean expressions. Source language programs may also be so interpreted. The correctness of a code generator can then be expressed as a simple relationship between boolean expressions. Code generators can then be calculated from their speci cation. 1

This paper presents a formal verification with the Coq proof assistant of a memory model for C-like imperative languages. This model defines the memory layout and the operations that manage the memory. The model has been specified at two levels of abstraction and implemented as part of an ongoing certification in Coq of a moderately-optimising C compiler. Many properties of the memory have been verified in the specification. They facilitate the definition of precise formal semantics of C pointers. A certified OCaml code implementing the memory model has been automatically extracted from the specifications.

In this position paper we overview on-going research work aimed at finding and formalizing laws of object-oriented programming. Rather than formal development, our main interest is to guide, justify and document informal object-oriented programming practices. In particular, we focus on laws that support software evolution practices such as introducing common analysis and design patterns. Moreover, contrasting with previous work on programming laws, we investigate both universal and method-specific laws. Keywords: Formal Methods, Object-Oriented Programming, Refinement Calculus, Laws of Programming, Programming Language Semantics. 1 Introduction The laws of imperative programming are well established and have been useful both for assisting software development and for providing precise axiomatic programming language semantic definitions [14, 17]. In fact, besides being used as guidelines to informal programming practices, programming laws establish a sound basis for formal and ...

Abstract. We give an overview of a proof-producing compiler which translates recursion equations, defined in higher order logic, to assembly language. The compiler is implemented and validated with a mix of translation validation and compiler verification techniques. Both the design of the compiler and its mechanical verification are implemented in the same logic framework.

Morgan and Back have proposed different formalisations of procedures and parameters in the context of techniques of program development based on refinement. We investigate a surprising and intricate relationship between these works and the substitution operator that renames the free variables of a program, and reveal an inconsistency in Morgan's refinement calculus. Back's formalisation of procedures does not suffer from this inconsistency, but his work is not as appealing to practising programmers as Morgan's calculus, whose distinctive feature is a large number of refinement laws. Here we benefit from both works and use Back's formalism as a model to derive the laws presented in Morgan's calculus. Keywords: program development, formal methods, refinement calculus, procedures, parameters. 1 Introduction Inspired by Dijkstra's work on weakest preconditions (wp) [5], Back [1, 3], Morgan [12, 11], and Morris [13, 15] have proposed three different formalisations of the stepwise refineme...

s and compressed postscript files are available via http://svrc.it.uq.edu.au A Formal Model of Real-Time Program Compilation Karl Lermer and Colin Fidge Software Verification Research Centre, The University of Queensland, Queensland 4072, Australia. Abstract Program compilation can be formally defined as a sequence of equivalence-preserving transformations, or refinements, from high-level language programs to assembler code. Recent models also incorporate timing properties, but the resulting formalisms are intimidatingly complex. Here we take advantage of a new, simple model of realtime refinement, based on predicate transformer semantics, to present a straightforward compilation formalism that incorporates real-time constraints. Key words: Refinement calculus; Program compilation; Program semantics; Real-time programming; Program verification 1 Introduction Compiler correctness is a significant concern for developers of safety-critical systems. However, verifying an indus...

Abstract: Most approaches to formal semantics are based on the assumption that all the constructs of a language are defined together. The details of the definition of each construct can (and usually do) depend on which other constructs are included in the given language. This limits reuse of definitions of common constructs. programming construct is defined separately and independently. The semantics of a full language is obtained by translating its constructs into the basic abstract constructs, whose definitions are thus reused verbatim. The frameworks of Modular SOS and Action Semantics can both be used in conjunction with the proposed approach. Some illustrations are given. Key Words: semantics of programming languages, action semantics, structural operational semantics, modularity

ing from Machine Details In order to derive a verified compiler, Muller-Olm first defines the effect of target machine (in this case transputer) instructions by simple source language processes, consisting mainly of delays indicating time consumption (as taken from the reference manual [Inm88]), assignments to variables representing the machine state, and some assertions. As an example, let us look at the definition of the effect of "jump" instructions: E 0 (j) w \Delta 3 ; IP; A; B; C; OReg:= IP + OReg; ?; ?; ?; 0 (1) This refinement relationship expresses that one may assume at least (w) the following about the basic effect (E 0 ) of a jump instruction (whose mnemonic is j): It takes up to 3 clock cycles, adds the contents of the operand register to the instruction pointer, makes the registers A, B, and C undefined, and clears the operand register. After this machine level has been defined, abstractions are introduced that correspond to increasingly abstract assembler languages. Th...

The present article addresses correct construction and functioning of large computer based systems. In view of so many annoying and dangerous system misbehaviors we want to ask: Can informaticians righteously be accounted for incorrectness of systems, will they be able to justify systems to work correctly as intended? We understand the word justification in this sense, i.e., for the design of computer based systems, the formulation of mathematical models of information flows, and the construction of controlling software to be such that the expected system effects, the absence of internal failures, and the robustness towards misuses and malicious external attacks are foreseeable as logical consequences of the models.

datatype Expr and an evaluation function eval ( 77 ) then define syntax and semantics of expressions where the state (SState) is defined as a mapping from identifiers to values. 77 % --- semantics of expressions --- eval(e:Expr)(s:SState) : RECURSIVE Value = CASES e OF const(val) : val, varid(name) : s(name), unopr(op,arg) : MUnop(op)(eval(arg)(s)), binopr(op,left,right) : MBinop(op)(eval(left)(s), eval(right)(s)) ENDCASES MEASURE e BY !! Since boolean expressions are treated in a similar way as expressions, we do not define them explicitly but instead suppose that an (uninterpreted) type BExp together with an evaluation function eval bexp : [BExp -? [SState -? bool]] is given. Syntax and semantics of statements are defined by importing the generic theories for simple statements and control structures: % --- import syntax and semantics of simple statements IMPORTING simplestatements[VarId, Expr, Value, eval] % --- import syntax and semantics of control structures IMPORTING ctrlstruc[B...