include "hdr1.html"; ?>
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
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.
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.
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:
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.
- 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.
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.
include "hdr2.html"; ?>