Elliott 803 Algol 60 Compiler

Run Time System Overview

This section covers the Run Time System, which was contained in the second tape (Tape 2) of the Algol Compiler System. This tape provided the neccesary routines to run a compiled program, and included basic memory management, I/O support routines and the Mathematical subroutines. There was also code to support indexing operations and procedure entry and exit.

Much of the comments in the index to Tape 1 apply to the code here, so I suggest that before you dive in here, if you have not already done so, you read that material first.

Linkage between Compiler and Run Time Routines

Since Elliotts had some previous experience in these matters, they obviously expected that the system would require changes to correct software problems. In order to minimise the effect of these, they devised a scheme for linking between the Compiler, the compiled code produce during compilation and the Run Time System. All entries into the run time routines are effected by means of a transfer vector, which is part of the Tape 2 software. The compiled code makes calls to run time support routines by jumping to addresses within this vector, which in turn contains branches to the actual routines. In this way, the users of the system can reasonably expect programs compiled with an early version of the compiler to operate correctly with a more recent version of Tape 2. Since many users relied on separate compilation and did much of their work with a limited set of programs, this was to their advantage. Any other scheme would have required them to re-compile all their programs with the new system before use. The slight overhead in using the vector is unlikely to cause any significant degradation in overall performance of the machine.

Procedure calls and stack management

The Elliott 803 was not designed as the ideal Algol machine. Since there are no index or base registers available, the stack management implicit in the Algol 60 concepts are not trivial to implement. Since many Algol programs do not contain recursive procedures the designers sensibly opted for an implementation that fits well with this assumption. All variables are allocated to specific addresses in memory and, provided recursion doesn't arise, this works well. If a procedure is called recursively, this is detected during procedure entry and a somewhat clumsy scheme of copying the local variables onto a stack is used. This implies that the reverse copy must occur on procedure exit. Purists may say that this is inefficient, but since it happens only for a limited number of applications, this provides a much more efficient implementation over all.

I/O Procedures and Support

Elliott Algol implements two additional statements to provide I/O facilities: The READ and PRINT statements. The manual describes these statements and a number of standard procedures which allow the programmer a fairly wide range of control over the I/O facilities.

There is a subtlety about the support procedures: they operate in different ways depending on whether they are called from within an I/O statement, or in isolation: For instance a call to READER(2); will switch all subsequent READ statements to the second tape reader. If, on the other hand you write:

        READ READER(2), X, Y, Z'

Then this affects only this statement. The data will be read from tape reader 2, but subsequent statements are unaffected. This is true of all of the I/O related procedures.

What actually happens is that the READ and PRINT statements compile into a call to a support routine that saves the current settings on the stack, then calls the routines needed to implement the data transfers and standard procedures within that statement, and finally calls a further support routine to restore the settings. Any changes made to the settings during execution of the statement are thereby cancelled out. Needless to say, you could achieve some interesting effects by calling a recursive procedure from within an I/O statement!

Mathematical Functions

I have not gone into much effort on the Mathematical functions. I believe they use a method based on Tschebychev Polynomial Approximations but I may be wrong on this. The code certainly appears to use something on these lines, with preliminary checking of argument ranges to ensure reasonable results.

Run Time System Index

As with Tape 1, the names, subdivision into files, and so on are based on my understanding (or lack thereof) of the code, and should not be assumed to correlate in any way with the original Elliott code. The resulting code, however, is exactly as in the distributed version that I have obtained.