# Compiler Operation

## Introduction

While it is, of course, possible to use a compiler without an understanding of how it goes about its actions, for a language like Sather which (among other things) permits the writing of concurrent and distributed programs, some idea of what has to go on may help in writing not only correct, but also efficient programs.

While different implementations will necessarily vary in detail, the general principles of operation described in these notes apply to most likely implementations.

In the course of compiling a program which is spread among many files of source text, the compiler has to be made aware of various properties of the program and of the target machine.These are properties which it will need to use in making decisions about how to ensure that the semantics expressed by those files of source text are faithfully converted into a form which can execute on the target machine(s) - to reproduce the actions specified for the program behaviour. These properties generally relate to all programs for a particular (possibly virtual) machine, although where concurrent programs are concerned a good compiler should accept hints from the user about how such a translation may be made more efficient for a particular program!

## Phases of Compilation

It is usual to consider program compilation as a sequence of translation steps - each one with a uniquely defined functionality. The sequence for the 1.3 implementation version for Sather is as follows -

1. Initialisation - this is the phase when the compiler finds and reads all of the machine/OS specific configuration information for all programs and, more specifically, for the particular program being compiled.
2. Finding Source Files - this is the phase which makes use of the module files - those written by the programmer and those which are part of the existing libraries (Required and other).
3. Syntax Checking - During this phase which starts off with the main program class file, all of the source files which are needed for the program are parsed - including any classes in library files.
4. Type Checking and Inheritance - this is the section of the compiler which checks for ambiguities and inconsistencies in the specification, implementation and use of program types. It needs to do quite a lot more work than does a compiler for a language which does not have inheritance.
5. Inter-class Checks - while the preceding phase of compilation was able to check type structures on their own, the use of objects of the various types in the program has to be checked subsequently - checking that names are correct and methods are used correctly.
6. Intermediate Code Generation - in the current Sather compiler the C low-level programming language is used as intermediate code - the files containing this have to be generated.
7. Translation to Executable Form - this phase currently invokes a C compiler for each of the C source text files generated in the preceding step. Given that the C code is compiler-generated, this should not result in errors except where some program has introduced a new interface to system services and this is incorrectly specified!
8. Binding - this phase is sometimes called linking and results in an executable image for the program. This may involve both static binding and the provision of run-time binding information. Again this should not result in errors if the interfaces to system services have been correctly specified!
9. Checking Unreachable Code - this phase is peculiar to Sather since a class compiled from some library may not use all of the facilities/features it contains. The compiler in a final phase does check this unreachable code after the executable program has been produced. See, however the compiler option -only_reachable.

## Initialisation

## Finding Source Files

## Syntax Checking

## Type Checking and Inheritance

## Inter-class Checks

## Intermediate Code Generation

## Translation to Executable Form

## Binding

## Checking Unreachable Code

To be completed!

| Contents |  | Syntax Errors

Comments or enquiries should be made to Keith Hopper Page last modified: Friday, 9 February 2001. |