Compiler Target Language Research Articles

A Completely Verified Realistic Bootstrap Compiler

This paper reports on a large verification effort in constructing an initial fully trusted bootstrap compiler executable for a realistic system programming language and real target processor. The construction and verification process comprises three tasks: the verification of the compiling specification (a relation between abstract source and target programs) with respect to the language semantics and a realistic correctness criterion. This proof has been completely mechanized using the PVS verification system and is one of the largest case-studies in formal verification we are aware of. Second, the implementation of the specification in the high-level source language following a transformational approach, and finally, the implementation and verification of a binary executable written in the compiler's target language. For the latter task, a realistic technique has been developed, which is based on rigorous a-posteriori syntactic code inspection and which guarantees, for the first time, trusted execution of generated machine programs. The context of this work is the joint German research effort Verifix aiming at developing methods for the construction of correct compilers for realistic source languages and real target processors.

A single intermediate language that supports multiple implementations of exceptions

We present mechanisms that enable our compiler-target language, C--, to express four of the best known techniques for implementing exceptions, all within a single, uniform framework. We define the mechanisms precisely, using a formal operational semantics. We also show that exceptions need not require special treatment in the optimizer; by introducing extra dataflow edges, we make standard optimization techniques work even on programs that use exceptions. Our approach clarifies the design space of exception-handling techniques, and it allows a single optimizer to handle a variety of implementation techniques. Our ultimate goal is to allow a source-language compiler the freedom to choose its exception-handling policy, while encapsulating the architecture-dependent mechanisms and their optimization in an implementation of C--that can be used by compilers for many source languages.

Branching-time logic programming: the language Cactus and its applications

Temporal programming languages provide a powerful means for the description and implementation of dynamic systems. However, most temporal languages are based on linear time, a fact that renders them unsuitable for certain types of applications (such as expressing properties of non-deterministic programs). In this paper we introduce the new temporal logic programming language Cactus, which is based on a branching notion of time. In Cactus, the truth value of a predicate depends on a hidden time parameter which varies over a tree-like structure. As a result, Cactus can be used to express in a natural way non-deterministic computations or generally algorithms that involve the manipulation of tree data structures. Moreover, Cactus appears to be appropriate as the target language for compilers or program transformers. Cactus programs can be executed using BSLD-resolution, a proof procedure based on the notion of canonical temporal atoms/clauses.

Experience using an intermediate compiler target language for parallel machines

The generalised computational model of term graph rewriting systems (TGRSs) has been used extensively as an implementation vehicle for a number of, often divergent, programming paradigms ranging from the traditional functional programming ones to the (concurrent) logic programming ones and various amalgamations of them, to (concurrent) object-oriented ones. More recently, the relationship between TGRSs and process calculi (such as the π-calculus) as well as linear logic has also been explored. In this paper we describe our experience in using the intermediate compiler target language Dactl based on TGRSs for mapping a variety of programming paradigms of the aforementioned types onto it. In particular, we concentrate on some of the issues that we feel have played an important role in our work (in, say, affecting performance, etc.), the aim being to derive a list of features that we feel every language model which intends to be used as an intermediate representation between (concurrent) high-level languages and (parallel) computer architectures must have.

Designing a parallel object-oriented compiler target language (TOOL)

As the level of interface between software and hardware is continuously shifting, the requirement for standard points of reference becomes increasingly important. TOOL is an intermediate-level parallel language aspiring to meet this requirement by establishing a common target for compilation of a wide range of high-level object-oriented languages and also, of process-oriented languages. TOOL exhibits the major object-oriented features, including data abstraction, multiple inheritance and dynamic binding. In addition, parallelism, although inherent in the computational model, is further supported by providing: (a) asynchronous message passing and synchronization mechanisms, (b) support for “autonomous” objects (ie. permanently active), and (c) special facilities for object allocation and migration.

An applicative compiler for a parallel machine

A compiler for the applicative language HOPE is described. The compiler is itself written in HOPE and generates a machine independent compiler target language, suitable for execution on the parallel reduction machine ALICE. The advantages of writing a compiler in a very high level applicative language are discussed, and the use of program transformation and other techniques to turn the initial 'runnable specification' into a more efficient (if less clear) program are outlined. Extensions to the HOPE language and the compiler which can exploit the parallelism and various execution modes of ALICE are described.

A Proposed Target Language for Compilers on Atlas

A compiler which treats a whole program as a unit can obviously produce its output in the form of binary words exactly as they are to be stored for execution. There is no need in this case for any intermediate form of storage. However, experience in using automatic programming languages has shown the enormous advantage of allowing the programmer to split up his program into more-or-less independent routines, to limit the scope of certain identifiers. There is a considerable difference between the processing which has to be carried out inside each routine and that which links routines together. We emphasize this difference by using the word compiler or assembler to designate the processor for individual routines, and loader for that which links them together before initiating execution. We thus distinguish compile time, load time, and execute time. An appreciable part of the work of a compiler consists of the treatment of cross-references of one sort or another: identifiers and statement numbers, both of which play a very important part in automatic programming languages. The processing of cross-references is roughly proportional to the square of the size of the program or routine being compiled, and so it is advantageous to keep the routines small. If a large program can be broken up into ten routines of one-tenth the size, compiling time will be considerably reduced. In general, a loader does not need to be such a sophisticated processor as a compiler, and cross-references between routines can be dealt with in a simpler way, giving a net gain. With the technique of independently compiled routines, alterations to a program do not require the whole program to be re-compiled: only the relevant routines. Consequently, programmers are not discouraged from making corrections in source language, rather than in binary.