Atlas Autocode(ID:1840/atl003)

Algol-like high-level Autocode 

• Country: uk
  • languages for uk
  • uk/1964
• Began: 1964
  • Languages for 1964
  • 1960s languages
  • Third generation
  • Early Cold War
• Type:Early Autocodes
  • Early Autocodes
• Sammet:MLT
  • MLT
  • MLT/1964
  • MLT/uk

• Stack

Rohl, J S "The influence of programming languages on the design of MU5" view details External link: Online copy Abstract: Atlas was a wonderful machine, with over 1000 instructions, 128 registers in an architecture that allowed double modification, and an address space of 24 bits at a time when stores were measured in kilobytes. Unfortunately compiler writers were unable to use these facilities to the full - or anywhere near it. Almost all of the bits of compiled code were zeroes! For MU5, for the first - and probably the only - time programmers were given the task of designing the order so that they could fully utilise it. In this paper I describe why compiler writers were unable to use Atlas at all well, and how we designed the MU5 order code to enable us to compile code more effectively.

Extract:
As Tony Brooker has pointed out, when Atlas became operational, a wide variety of programming languages was in use throughout the world. He mentions both general-purpose, scientific and commercial languages such as Fortran, Algol and Cobol, and special-purpose languages, such as APL (for processing arrays) and Simula (for simulation). We add here others such as Lisp, a list processing language, and Snobol, a string-processing language.

On Atlas we dealt with the general-purpose languages fairly well. We created Atlas Autocode, the last in the line of workaday autocodes. This was an Algol-like language, which melded the newer language features that Algol was pioneering, with the one-pass, line-by-line structure of the earlier autocodes.

We didn't attack the special-purpose ones specifically. We did though extend Atlas Autocode to list processing facilities and even compiler-compiler facilities. A very versatile language it became!

This was a radically different situation from those that pertained with the earlier machines. In those earlier times the compiler writer was a language designer; and the languages designed reflected very closely the hardware for which they were designed. In Manchester these languages were called "autocodes", a term that later came to refer to lower-level languages. This was quite unfair, of course: the autocodes were the first step in the development of programming languages.

The newer languages, on the other hand, were designed quite independently of any computing machine. The Algol 60 Report, a classic example of a formal language definition - and a model still today - does not mention the word "computer". This was clearly the right approach, what we today call the "top-down approach". The language designer had in mind the problems that the users needed to solve, and the ways in which they thought about the problems: the language design reflected all these aspects. In later times E. W. Dijkstra was to phrase this idea as - since I cannot remember where he said it my quotation is approximate - "we are not here to program computers: computers are here to run our programs."

How this was to be achieved was not of major concern to language designers. They assumed that it was a fairly mechanical process, which could be left to the professional compiler writer. Sometimes they were wrong, and languages were designed that were impossible to compile. In Algol the dynamic own array could not be implemented. (It's not clear what it meant either - itself a pointer to the compiling problem that it presented.)

The world of the compiler writer had become quite separate from that of the language designer, though, of course, there were areas, generally close to the machine itself where the two worlds merged. A simple picture says it all.




Extract: Facilities of Atlas that we could not utilise
Facilities of Atlas that we could not utilise
It is said that the best car you ever have is your first. I believe it is true of computers, too; and so I still see Atlas as a wonderful machine. Yet there were many of its facilities of its instruction set that we could not use. The instruction occupied 48 bits partitioned as follows:



The rich instruction set
Atlas had 1024 instructions - machine codes and extracodes - of a wondrous variety. Yet the compilers could make use of only a few, perhaps 30 or 40. It simply wasn't possible for a compiler writer to use floating point instructions that had special rounding, for example, or extracodes corresponding to mathematical functions that weren't available in the language being compiled.

The very large address field
Atlas had a 24-bit address, which, given the very high costs of core-store, was generous in the extreme. We used the full address space very effectively, by treating it as a virtual address - the one-level store concept did all the store management for us. But the code itself had very short addresses, typically no more than 4 or 5 bits. The full address was spanned by using modification. That is the registers tended to hold large addresses, rather than the instructions.

The possibilities of double modification
The instruction set dealt with both floating point numbers in the accumulator, and integer arithmetic in the 127 registers that we called B-lines. For the integer arithmetic BA specified the register in which the operation took place, and BM could modify the address part. For floating point arithmetic an address could be modified by 2 registers. For stack-based languages it was impossible to use double modification. Static variables, such as scalars, were at a known position from the start of a stack frame, whose origin was held in a register; dynamic variables, such as arrays, had their (full) addresses held in some static variable. For both types of static variable, an address of only a few bits was required.

The large number of registers
The Atlas compilers, constructed with the aid of the Compiler Compiler (CC), made good use of the registers. The name Compiler Compiler is a misnomer: it didn't compile compilers; it expanded to become a compiler for each of the languages it was used to develop. Compilers process characters, not numbers, so they have the potential to use the registers. Since the CC made good use of the registers, so too did the resulting compilers. This was done by hand: during development, well before the machine became available, the routines were written with symbolic registers; towards the end a large tree structure describing the interdependencies of the routines was drawn up, and an allocation of registers was made.

The compiled programs, on the other hand, could not make much use of the registers. All floating point operations used the (single) accumulator, and the registers were used as stack pointers, which marked the start of the active stack frames. For most programs two or three were adequate. We set a limit of 10, though this was never ever reached. Because no facilities were provided for operating between floating point numbers and integers, we could not hold the integers in registers: we had to store them as floating point numbers. They were in a special non-standard form, because we needed to be able to put them into a register for implementing array subscripting. High-level languages do not generally distinguish between integers that are to be used for subscripting and loop control and integers that are the data type of the calculation.

      in [ACM] CACM 21(01) (January 1978) view details