Jump Over Left Menu
Fortran on Atlas: The Hartran System
E B Fossey and Barbara Stokoe
In 1960, when the purchase of Atlas was being discussed with the manufacturers, the programming language Fortran was already widely used in America but much less used in England. This is probably because it had been implemented mainly on the larger IBM computers - the language was produced by IBM - and not many organisations here owned or had access to one of these machines at that time. It was clear to all the people concerned with the Atlas project that a good Fortran compiler would be essential, and the need was made particularly great by the expectation that the Atomic Energy Authority, which was probably the biggest user of Fortran in England, would want to use a large amount of time on Atlas. Nowadays, of course, no manufacturer would sell a big computer without a Fortran compiler, but the situation was different in England in 1960; and it was arranged that the Computing Group in A.E.R.E. Harwell would undertake the production of a Fortran system for Atlas, with assistance from Ferranti. The original ideas on which the system was based were produced by A. R. Curtis and I. C. Pyle of Harwell. After the Atlas Laboratory had been formally set up in December 1961, several of the system programmers transferred from Harwell to this, new people joined and then the centre of gravity of the project gradually moved over to the Atlas Laboratory until finally all the work was being done there, with the present authors in charge.
The object was to write an operating system - called Hartran, to convey the idea of a Harwell version of Fortran - which would give the user plenty of flexibility in presenting work to the machine and getting results from it. It was to comprise a compiler for a form of Fortran which would be essentially IBM Fortran II, with some extensions and the removal of some restrictions; an assembler for a mnemonic form of Atlas machine code, to be called ASP - Atlas Symbolic Programming; and a loader for a language BAS - Binary and Arbitrarily Symbolic - into which Fortran and ASP would be compiled. It would allow options like compile-and-run, production of binary cards, production of program listings and use of either IBM or Ampex tape as Input/Output streams, and fairly extensive diagnostics were to be provided. All this was achieved and the system is running substantially as was planned.
A major decision taken at the start of the project was to write the compiler itself in Fortran. The reason for this was that at that time no Atlas computer was available, and therefore, if work was to start quickly, either a simulator for Atlas would have to be written for some other computer, or the compiler itself would have to be written in Fortran: it could then be developed on one of the U.K.A.E.A.'s IBM machines. The second course was chosen and the work done on the 7090 at Risley.
To see that the proposal is, in fact, practicable, let us take machine A equipped with a Fortran compiler and a loader. Then using this machine is represented diagrammatically below:
We can readily see that this system allows any program written in Fortran to run on machine A. Now, suppose that the program is in fact a Fortran compiler for machine B written in Fortran. Then this program will run on machine A producing output suitable for loading to machine B. The diagram below shows how machine B would be used.
Fortran Compiler for Machine B
Since the Fortran compiler for machine B is written in Fortran, we can now pass it as data through the Fortran compiler for B running on machine A, obtaining output capable of being loaded on machine B. We thus achieve the objective of getting a Fortran compiler for machine B. It will be seen that what is required is a loading program for B, which must be written in the machine language of B. Also, the Fortran language of machine B must include the Fortran language of A as a subset; and a further requirement, which is perhaps less obvious, is the provision of a library of input and output routines for machine B.
The compilation process takes place in three stages, namely:
- statement analysis
- code generation
- storage assignment and assembly.
In statement analysis we are concerned with recognising the different statements and determining the meaning of the arithmetic expressions occurring within them. For this part almost all the program is written in Fortran. Likewise, in the code generation phase we employ an assembly code which obviates the necessity to generate actual machine instructions. In the final stage of storage assignment and assembly, the Atlas machine word structure becomes an important factor, and so routines written in machine language to achieve appropriate binary digit packing were required.
The design of the compiler makes a number of assumptions which now lead to some operational difficulties. The Atlas computer has a Supervisor program which schedules the activities of the computer to exploit the use of its resources. Thus its aim is to share memory between about three programs, so that jobs liable to be waiting for the completion of magnetic tape transfers do not leave the machine idle. The Fortran compiler is designed with the time-sharing of only input and output assumed, and takes little account of the possibility that other programs may need to share the memory with it. Its development on the IBM 7090, where the whole machine is available to the single program, has put insufficient storage constraints on its size and the compiler is now a large program needing about forty thousand words of store for instructions and up to another fifty thousand for working areas. The complete system runs quite smoothly in spite of this demand for store.
If the compiler is small, then some saving in machine time accrues from combining the phases of compilation and loading. For a Fortran compiler written in Fortran, the compiler must be moved to avoid clashes in the use of the same areas of store. With a compiler as large as we have indicated, we have simply no alternative to treating loading as a separate phase from compiling.
A brief description of the system is just possible here. It gives facilities for users to write programs either in Fortran or the assembly code ASP, and to combine such programs with pre-compiled routines through a binary program loader. The activities of the system are controlled by sequences of directives, each distinguished by an asterisk in the first column of a card. Thus we have, to mention a few:
*FORTRAN *ASP *BAS *ENTER *DEFINE *RENAME
The directives cause the system to initiate some activity. Thus, *FORTRAN brings in the compiler to compile a Fortran program which follows it. Other languages could be incorporated into the system, provided only that a compiler into BAS was available for each one. Further information may appear with the directive: for instance a user may obtain a full listing of his Fortran compilation by using the directive
or, since cards of a compiled program in binary are normally produced their output can be suppressed with the directive
Facilities for the manipulation of symbols are given. Every Fortran program has a name and it is possible to change the name without recompiling it. For example, the routine PQR can be renamed XYZ with the directive:
*RENAME XYZ = PQR.
Binary pre-compiled routines are usually introduced by the directive
and this is perhaps the only directive which the user does not prepare himself. It is produced automatically as part of the output of the Fortran compiler or ASP assembler, and precedes the binary machine code of the routine. The user can present his routines in any order and may also present his own versions of system library routines. In fact, the system resembles the Fortran II monitor system developed for the IBM 709/7090 machines and contains a number of features which extend the utility of that system.
The system is used very heavily indeed by the Atlas computing service accounting for about 64% of the jobs run through the machine, or about 68% of the time. Most of the biggest programs are in Fortran. The compilation speed is about 500 instructions per minute. Execution speed of course varies enormously from program to program - we have observations ranging from about 1 to 20 times 7090 speed; very roughly, the machine runs Fortran programs at much the same speed as the IBM 7030 (Stretch).