Richard Bornat

Proving Pointer Programs in Hoare Logic

It is possible, but difficult, to reason in Hoare logic about programs which address and modify data structures defined by pointers. The challenge is to approach the simplicity of Hoare logic’s treatment of variable assignment, where substitution affects only relevant assertion formula. The axiom of assignment to object components treats each component name as a pointer-indexed array. This permits a formal treatment of inductively defined data structures in the heap but tends to produce instances of modified component mappings in arguments to inductively defined assertions. The major weapons against these troublesome mappings are assertions which describe spatial separation of data structures. Three example proofs are sketched.

Program logic and equivalence in the presence of garbage collection

It is generally thought that reasoning about programs in memory safe, garbage collected languages is much easier than in languages where the programmer has more explicit control over memory. Paradoxically, existing program logics are based on a low-level view of storage that is sensitive to the presence or absence of unreachable cells, and Reynolds has pointed out that the Hoare triples derivable in these logics are even incompatible with garbage collection. We present a study of a small language whose operational semantics includes a rule for reclaiming garbage. Our main results include an analysis of propositions that are garbage insensitive, and full abstraction results connecting partial and total correctness to two natural notions of observational equivalence between programs.

Jape: A Calculator for Animating Proof-on-Paper

If you suppose that it would be pointless to simulate proof-on-paper; if you imagine that all the problems of interactive theorem-proving are solved; if you are sure that making a user interface is a matter of bolting a bit of Tcl/Tk onto a theorem-proving engine; if you believe the more buttons the better in a graphical user interfaces — read no further, lest your prejudices be disturbed!

Procedure Call and Return

This chapter discusses the design of code fragments which support procedure call and return in both recursive and non-recursive programming languages. To aid the discussion in later chapters it includes a model of procedure call and return based on the notion of a procedure activation record. A procedure activation is a special case of a ‘micro-process1’, and the same model can explain the operation of languages such as SIMULA 67 whose control structures are not restricted to simple procedure call and return. It also helps to explain how restrictions on the use of data and procedures in the source language can allow restricted (and therefore less costly) implementations of the general procedure call and return mechanism. The mechanism of procedure call and return in FORTRAN is briefly discussed: then I concentrate on the mechanisms of stack handling which are required to implement procedure call and return in a recursive language on a conventional object machine.

LR(1) Syntax Analysis

Theoretical studies of the properties of programming language grammars and of algorithms for syntax analysis have always been partly motivated by the search for a truly automatic means of constructing a syntax analyser. In the early 1960s so called ‘compiler-compilers’ were popular. One of the earliest was developed at the University of Manchester (Brooker et al., 1963): it included a parser-transcriber which took a syntax description and without alteration transcribed it into a top-down syntax analyser1. Foster’s SID (Foster,1968) was the first of many parser-generator programs which went further so far as syntax analysis was concerned: its input was a type 2 grammar, on which it performed most of the operations discussed in chapter 16 to produce a one-symbol-look-ahead grammar, which it finally transcribed into an ALGOL 60 program. The transformations required to make a grammar one-track or one-symbol-look-ahead aren’t always simply mechanical, however, and in practice a top-down parser-generator like SID often fails to complete its task. Parser-generators for top-down analysers were little used, therefore, and most syntax analysers were written by hand using the techniques discussed in earlier chapters.

Notation and Formal Language Theory

The theory of formal languages, so far as it is applicable to compiler writing, covers only issues of syntax: it describes those arrangements of symbols which constitute executable (runnable) programs in a programming language. It isn’t concerned at all with the semantics of those programs: what they ‘mean’ or what will be the effect when you run them. Sections II and III above assume an intuitive understanding of the semantics of languages such as PASCAL, FORTRAN, ALGOL 60 or ALGOL 68 and that’s as far as this book goes in the discussion of programming language semantics.

Arguments and Parameters

The tasks set out in figure 11.1 of chapter 11 include the preparation of argument information — for example the value of an argument expression, a pointer to an argument variable or a pointer to an argument vector — and the placing of this information in a location within the new procedure activation’s data frame. This chapter concentrates on this apparently insignificant aspect of run-time support in part because it is so often inefficiently implemented in practice and in part because compilers do not always perform all possible syntactic checks at compile-time.

Phases and Passes

The most obvious overall task of a compiler is to read a program in one language — the ‘source’ program in the ‘source’ language — and to translate it to produce an equivalent program in another language — the ‘object’ program in the ‘object’ language. The object language is usually the machine language of a computer, or something close to it, and the source program is usually in a ‘high-level’ language such as FORTRAN, PASCAL, ALGOL 68, SIMULA 67 or BCPL, because translation from high-level language to machine language is the practical problem which compilers exist to solve. Compilers can be written to translate from any kind of programming language into any other, however, with varying degrees of efficiency of the resulting object program.

Introduction to Translation

The most important task that a compiler performs is to translate a program from one language into another — from source language to object language. Simple translation is a mechanism which takes a representation of a fragment of the source program and produces an equivalent fragment in the object language — a code fragment which, when executed by the object machine, will perform the operations specified by the original source fragment.

Top-down Syntax Analysis

The most difficult task when writing a top-down syntax analyser is that of preparing a grammar which is suitable for top-down analysis. Once you have manipulated the grammar so that it possesses certain simple properties, which I describe below, it is trivially easy to write a syntax analyser as a collection of mutually recursive procedures, one for each non-terminal symbol in the grammar. Each procedure has the task of recognising and analysing a section of the input which represents a phrase described by its particular non-terminal symbol. It does so by checking the output of the lexical analyser, and by calling procedures associated with the non-terminals of the grammar, in the sequence defined by the production on which it is based.