PROCESS III, a compiler for the 1ESS

“We say the programmer writes a source program in some kind of symbolic language, whereas the central control executes an object program in its machine (binary) language.” Martellotto et al, “PROCESS III – a Compiler-Assembler for No. 1 ESS”. BSTJ 43.5 (1964)

One of the things that I love about reading old documents on computing is seeing explanations of things that seem so completely obvious to us now, but written for an audience that might be encountering the idea for the first time. Much like my Windows 3 manual that explains how to use a mouse, the authors of this paper didn’t consider knowledge of compiled language to be background. This wasn’t unreasonable, FORTRAN was only seven years old and a large range of software, particularly outside of academia and management information systems, was still written directly in the machine language.

A month ago I discussed the architecture of the AT&T 1ESS, the first computer-controlled telephone switch and a great example of early embedded computing. In this article, I’ll take a look at the language created to program it: PROCESS III, the PROgram to Compile ESS programs.

The original BSTJ paper on PROCESS III starts out by noting that the ESS software consists of over 100,000 instructions, each 44 bits in length. Assuming 8-bit bytes (not used by this machine but useful for comparison), that’s about half a megabyte of machine code: roughly the same size as the xterm binary, but there’s an entire operating system in this space. “To write such a program in binary machine language is clearly impractical,” the authors note, with a sense of absoluteness that implies that they might have tried.

PROCESS III is referred to in the paper as a compiler-assembler because it does some of both. PROCESS III routines are freely mingled with direct assembly instructions for the machine, resulting in a product that looks something like assembly with control structures added. PROCESS III instructions are essentially what you would expect: branching, looping, and control transfer to subroutines. PROCESS III routines are actually macros, as discussed later, making the language extendable.

PROCESS III, as you might expect from the embedded nature of the 1ESS, does not run on a 1ESS. The compiler itself is written for IBM 7094, and produces object code which is then written to the read-only “twistor memory” cards from, which the 1ESS reads its instructions, by a dedicated twistor writing machine. The introduction of the paper describes a few requirements for PROCESS III, one of which is a rather interesting result of this arrangement: PROCESS III must have the ability to update sections of the object program without disturbing other sections, so that updates can be performed by only replacing a few of the twistor cards. Towards this purpose, PROCESS III’s output is relocatable, with jumps either being absolute within a small section or pseudo-addresses referring to other programs. These pseudo-addresses are resolved on the fly by the program that actually writes to the twistor cards, and the authors even refer to this process as linking (although the program that does it is called the loader).

The PROCESS III compiler also features a primitive memory-management scheme called the Compool, for “communications pool.” Compool is essentially just a system of names that label various sections of the call-store working memory, and memory references are made relative to these names. This allows for easy changes to the layout of the memory, without the need to modify huge portions of the software. The paper makes it clear that this was motivated in large part by logistical concerns around the multiple engineers on the project, and the Compool has one rather cute feature to this end. When the memory scheme is changed, PROCESS III automatically determines if any parts of the program need to be recompiled to change memory addresses and, if so, prints a list of such sections that can be distributed to the engineers responsible for each one. “They only need recompile without concerning themselves as to precisely what call store changes have been made.”

The memory areas defined in the Compool can have one of several data structures which are vaguely familiar to modern programmers. The first described is the scatter table, which can be thought of as a 2D array of packed structs, each struct being one word in size. There is also a table, which is similar except that the different first-dimension tables can have independent structures. Finally, there are simply blocks, which have no particular structure.

The syntax for describing the structures within tables is rather amusing, the paper gives the example of the definition “ABB———–CCCCCCCC”, which reserves a one-bit field (A), a two-bit field (B), an 8-bit field (C), and leaves 12 bits unused. Later, these letter-identified fields are given more useful names.

The main feature of PROCESS III, though, is its system of macros. Macros in PROCESS III are what a modern programmer would call a subroutine or even a function: they allow for tidy reuse of parameterized code. There are two types of macros. The first are actually included as part of the Compool and so are available globally, today we might think of these as a standard library. The second type are defined within program sections, independently by the engineers responsible. Macros can refer to their parameters using a system that is surprisingly complicated, but retains a great deal of generality.

Now, as previously promised, I will soon put together a post on the third part of the magic of the 1ESS: the emergency action system, which monitored the redundant central controls to detect and intervene in any malfunctions. After that, maybe I’ll manage to get my mind off of telephone switches for a while.

  • history/computers/processiii.txt
  • Last modified: 2020/11/16 23:46
  • (external edit)