Bootstrap Loader
Global definitions
Main data area
Various linkages
Pack identifer
Lexical analysis
String scanner
Get Lexical Token
Stack management
Storage Management
Error recovery
Error reporting
Algol keywords
Lookup keywords
Standard procedures
Lookup identifiers
Code Generation(1)
Code Generation(2)
Load expression
Obtain a value
Operator generation
Code templates
Final assembly
Operator priorities
Operator deferral
Elliott function call
Compile variable
Compile subscript
Boolean Expression
Boolean clause
Compile primary
Integer expression
Simple expression
Label expression
Conditional expression
Compile expression
Compile assignment
Compile declaration
Compile FOR statement
Precompile() function
Print statement
Procedure calls
Read statement
Compile statement
Process a title
Entry and control
Compiler maintenance
Binary input

Compiler Index

This is the index page into the various source files that make up Tape 1 of the Elliott Algol 60 Compiler. This implements the compilation phase of the Algol system. Once a program has been compiled, it can be executed, but in order to do so, it needs support routines which are contained on Tape 2. The compiler itself needs access to some of the routines in Tape 2 and so both tapes must be loaded before compilation can commence.

Some details of how the system is used

Tapes 1 and 2 are loaded under control of the fast bootstrap routine, and then the compiler is entered in load-and-go mode. In this mode, the compiler generates code in store and on completion can enter the code and execute the program. If the program is too large to be held in store, operation switches to compile to tape mode and the code generated so far is output to paper tape. In order to run this, only Tape 2 is required, so the space occupied by the compiler itself is then available. The format of the paper tape output is unusual as it involves winding the tape backwards, so it is read in reverse order. This allows the compiler to write summary information on the end of the tape to be read in first. The rest of the program is then loaded in reverse sequence into store, starting from the end and working back to the start. This permits various instructions references to be resolved in a convenient, if slightly confusing manner.

If a program running in load-and-go mode needs more store than is available, it can overwrite the space occupied by the compiler Tape 1, but this will naturally mean that the operators will need to re-input Tape 1 before the system can compile a further program.

Operator Procedures

During operation, the compiler will enter busy waits and various points in the process. These are usually to allow the operator to change the paper tape, or to mark the source tape if an error has been detected. The loudspeaker on the console is used to determine which state the machine is in - after a failed compilation the compiler expects to compile another program, whereas if it was successful, it expects to run the program, and a data tape may need to be loaded. There are two distinct wait states therefore, and these are signalled with different pitched noises from the loudspeaker.

There are a number of alternate entry points into the compiler, and these are documented in the Compiler Description Manual.

Compiler Structure

The compiler operates in a recursive descent manner, with various subroutines to process various syntactic entities. The compiler can be split into several distinct parts:

• Lexical Analysis, which is fairly intricate, but short;
• Syntactic Analysis, which is a major part, but is fairly straightforward if you understand the syntax;
• Code Management, which handle the storage of the generated code, and provides a template mechanism for generating short segments of code. I'm not convinced that I understand this fully, as yet, so don't blame me if the comments or names are misleading.
• Error Recovery, this is fairly simple, since it simply outputs a short error message (with an error number, documented in the manual) and then attempts recovery. This is not always succesful, but in many common errors it seems to work OK.

In addition to the above, there is a chunk of code concerned with initialising the state of the compiler, and odds and ends that don't fit into any well-defined category.

There are several data areas distributed across the compiler. These have been coalesced into a single file (data.t2) for convenience. I had hoped to separate out the data relating to various sections of the code, but the usage is haphazard, and the compiler writers have taken the liberty of re-using some variables for totally unrelated purposes! This could lead to major problems, but Elliotts must have had strict controls over who did what, as it all seems to work. The result is not pretty, but getting a compiler of this complexity to run load-and-go in 8K words was an achievement that I find amazing.