The Atlas Fortran compiler and its associated programming system were intended to ease the transition in 1964 of Harwell's computing work from the then current computers to the new Atlas. To do this, we had to have the compiler available when the Atlas arrived. So we made a cross-compiler on the IBM 7090, which produced cards that could be loaded onto the Atlas, needing only the loader on the Atlas itself. By writing the compiler in Fortran, it could translate itself. I think this was the first Fortran compiler written for an non-IBM computer, and the first use of this bootstrapping technique for a compiler.
Jack Howlett was the head of the computing group at Harwell when I started there in 1958. We had a Ferranti Mercury computer, but sent a lot of work to be done on the IBM 704 computer at Aldermaston. Almost all the programs were written in machine code, although an increasing number were being written in Mercury Autocode.
Howlett (1989) wrote for the Silver Anniversary of Atlas about the work that had been done to get a British computer for Harwell. The Manchester design for MUSE was chosen, to be built by Ferranti, and called Atlas. We at Harwell prepared for the transition from about 1960. Clearly programs in machine code would have to be re-programmed - but what to?
We knew about Fortran from IBM, and about Algol, as well as machine-specific autocodes. We decided that our strategy would be to start using Fortran on the IBM computers, and to make a compiler for it on Atlas. We knew that would be possible, but at that time no-one had made an Algol compiler. See also Curtis (1960).
We knew that Fortran was slightly machine- specific (it has particular instructions for dealing with the switches and lights on the console of the IBM704), but decided that a version for Atlas would be easy for Harwell programmers to adopt, after they had gained experience on the IBM computers at Aldermaston. The several versions of Fortran had slight variations, which I called "Dialects of Fortran" (Pyle1963). Atlas Fortran was in this spirit. The extensions are outlined in the implementation paper (Pyle1964)
We had no previous experience of writing compilers, but did have access to IBM's documentation about the Fortran II compiler for the 704, including the assembly language listing (about 7 or 8 inches high of line-printer listing paper), and Sheridan's description of the expression analyser. But for writing in Fortran, we were on our own.
Harwell's legal team wrote to IBM to ask whether IBM considered the name "Fortran" to be proprietary, in which case we would have had to invent a different name for the language. Fortunately for us, IBM raised no objection to our using the same name.
We knew that it would need a symbolic loader, to link at run-time the several sub-programs that were compiled separately, analogous to the BSS (Binary with Symbolic Subroutines) loader for the 704. Alan Curtis and I designed the BAS (Binary and Arbitrarily Symbolic) loader for the Atlas, making a slight extension to BSS, particularly to deal with Block Common in Fortran IV.
We also recognised that Fortran was intended for working with numbers, not characters. The basic technique for dealing with characters was explained in 1962 CACM vol 5(8), using input/output in an unconventional way. As a demonstration of feasibility, I wrote an assembly program for Atlas, called ASP (inspired by the SAP assembler for the 704). This produced a listing in octal, and cards in BAS, from a text in a mnemonic order code for Atlas.
Although our motivation was based on using Fortran, we recognised that other programming languages were in the air, and compilers being written for the Atlas. There was nothing Fortran-specific in the design of BAS, and we hoped that other compiler-writers would recognise the value of separate compilation of sub-programs, and use BAS as the target language. The paper was called "A proposed target language for compilers on Atlas" (Curtis amp; Pyle 1962), but I do not think anyone else used it. Neither was much use made of the "parameter" facility which it introduced, intended to give more generality to storage allocation for large arrays.
BAS was intended to be used with punched cards. We designed a binary card format
specifically for BAS. A typical card is illustrated in:
http://www.chiltoncomputing.org.uk/acl/technology/atlas/p013.htm
copied at the end of this paper.
The Atlas Supervisor, [more to come here] provided for the execution of a series of "Jobs", under the control of what the supervisor recognised as a compiler. This was not appropriate for Fortran, as there could be a number of sub-programs to be linked together. On the IBM computers this is done by the Fortran Monitor System (FMS). For Atlas, we introduced the concept of a "Local Operating System", or Programming System, to control the processing of individual programs. We called it Hartran, so a job with sub-programs in Fortran was introduced by the directive "COMPILER HARTRAN" - which led to considerable confusion. See Fossey amp; Stokoe 1966.
In the HARTRAN system, a program can consist of a number of routines, each of which may be written in any source language for which a compiler exists, producing its output in BAS.
An overview of the Atlas Fortran compiler was given in Chapter 6 of "Introduction to System Programming", ed P Wegner, pp86-100, Academic Press (1964). I include below a copy of the diagram showing the bootstrap process, with the boxes showing the executing machine or language, and the translation carried out. Here are a few further points, which I remember rather hazily! There is a little bit of repetition from my earlier papers.
Working on the Fortran compiler, we created hundreds of subroutines. To avoid conflict about names we had a simple convention: whoever invented a subroutine gave the first letter of their surname as the first letter of the subroutine name. Thus all my subroutines began with "P", all Barbara Stokoe's began with "S", Bart Fossey's with "F", etc. If the text of the compiler survives anywhere, this will allow the authors to be identified!
The format processing facilities of Fortran are very powerful, but not normally available for internal use, as they are tied to input/output operations. The technique (Pyle1962) of using the input/output buffer without an actual input/output operation allowed us to read a card, than process the characters on it as though they were integers. We used this on the IBM 7090, and (presumably) made similar subroutines on the Atlas.
Fortran statements are distinguished by rather complicated rules: there are no reserved words, and variable names can be the same as those that distinguish statements. The trick case is the statement
DO 5 I = 1.3
which is an assignment of the value 1.3 to the variable called DO5I! However, if the full stop is changed to a comma, it becomes a statement introducing a DO loop.
So we determine the type of each statement by a series of scans; first to look for parentheses and the equals sign, excluding comments cards and text strings (Hollerith). After excluding arithmetic statements, we distinguished further by testing the first letters of the statement. (See Pyle1964, section 12)
The Atlas was very generous in the provision of index registers, called B-lines. However, they had to be protected from interference between one subroutine and another. It was not feasible to allocate them relatively (like addresses for main memory: relocatable binary), so each subprogram used as many B-lines as it needed, but had to protect them carefully. A basic design decision was whether to save and restore index registers within a subroutine that called another, or to rely on the called routine to protect them. To resolve this issue, I collected about 30 subroutines from typical uses, and analysed them to decide where the balance lay. It turned out that most used only a few index registers, and the best solution was to save as many as would be needed on entry to the subroutine, and restore their original values just before exit. I do not know whether anyone carried out measurements to see whether this decision was justified in practice.
I still do not know how extensively the B-lines from (say) 16 upwards (below 90) were used - I suspect very little if at all.
Names in Fortran could be up to six characters long, starting with a letter. (This corresponded to six 6-bit characters in a 36-bit word on the 704/7090). They did not have to be declared before use. So the compiler has to build a symbol table to contain the details of each name in the subprogram. In order to be able to access the table quickly, we arranged for it to be sorted to spread out likely names, accessed by an encoding of the name itself. This technique was subsequently called "hashing". I do not remember it being written up anywhere.
The BAS loader made full use of the main (onelevel) store of Atlas, treating major regions of address space for different purposes, according to the most significant octal digit of the address. Addresses starting with 0 were the "global region", those starting 1 were the "chapter region" (corresponding to the use of CHAIN in Fortran); those starting 2 were the "block region" and those starting 3 were the "common region". Of course, addresses with most significant octal digit 4 and above were reserved for special uses by the supervisor.
In retrospect, I regret not having arranged to measure anything about the compiler, so I have no information about the number of subroutines, frequency (or paucity) of errors found during debugging, throuput or execution time. Perhaps someone else did that?
In retrospect, I think there are two important consequences from our work on Atlas Fortran. The success of separate compilation of subprograms was emphasised in the Flowers report (Flowers1966) which called for:
In other words, the Fortran model of a program was implied, disregarding the fact that Algol60 did not have the concept of separate compilation of sub-programs.
The other important outcome, not directly from Atlas, but from Harwell's decision to program in Fortran, was the Harwell Subroutine Library, began in 1963 by Mike Powell and Mike Hopper, now called HSL and developed at the Rutherford Appleton Laboratory.
I think it fitting to conclude with a tribute to Alan Curtis, who died in 2008. Alan was a wise and inspirational group leader, whose insights and guidance were influential on all who worked with him. Primarily a mathematician and numerical analyst, his influence was felt on computer languages and computer-based systems. Alan had been involved with Atlas from the design of the order codes, and was the strategic thinker behind the work reported here. Under his guidance, I had the most productive years of my life.
Howlett, J.: "Atlas Laboratory: Origins," Flagship issue 5, Sept 1989 (Atlas Silver Anniversary
Issue): in
http://www.chiltoncomputing.org.uk/ccd/literature/ccd_newsletters/flagship/p005.htm#s5
Pyle, I C: "Character manipulation in Fortran" CACM vol 5(8) (1962)
Curtis, A R & Pyle I C: "A proposed target language for compilers on Atlas", Computer Journal vol 5(2) pp 100-106 (1962).
Pyle, I C: "Dialects of Fortran", CACM vol 6(8)pp462-467 (1963)
Pyle, I C "Implementation of Fortran on Atlas", in "Introduction to System Programming", ed. P. Wegner, Chapter 6, pp86-100, Academic Press (1964)
Fossey E B & Stokoe B: "Fortran on Atlas: The Hartran System" Atlas Computer Laboratory (1966), in http://www.chilton-computing.org.uk/acl/applications/hartran/overview.htm
Sheridan, P: "The Arithmetic Translator-Compiler for the IBM Fortran Automatic Coding System", Comm A.C.M. vol 2(2) (1959)
Curtis, A R: "Preparation for a Possible ATLAS Computer at AERE" (1960) in http://www.chiltoncomputing.org.uk/acl/literature/earlyhistory/p003.htm
Flowers, B H: "A report of a Joint Working Group on Computers for Research" (The Flowers Report), Cmnd.
2883, HMSO (January 1966), at
http://www.chiltoncomputing.org.uk/acl/literature/manuals/flowers/p002.htm
http://www.chilton-computing.org.uk/acl/technology/atlas/p013.htm
See also
http://www.chilton-computing.org.uk/acl/technology/atlas/overview.htm
