The 1ESS Central Processor and the Rightmost One

By the 1960s, it became apparent that the Strowger (or step-by-step) and panel switches then in use by AT&T and the Bell System would not be sustainable as the number of telephone lines in urban locations and volume of traffic increased. As a solution, Bell Laboratories started designing the first Electronic Switching System, or ESS, which they creatively named the Number One ESS or 1ESS for short. The first 1ESS went into service in 1965, the same year as IBM began delivering the System/360, and so in many ways one of the most important years for business computing.

The 1ESS was an impressive machine: it readily served tens of thousands of lines (up to 65,000), was relatively compact, and had advanced reliability and diagnostic features that would impress many modern computer engineers. Most importantly to me, it was controlled not by electromechanical logic but by a bona fide digital computer. This makes the 1ESS a fascinating case study in early embedded computing, and one designed by an organization obsessed with quality and reliability.

Fortunately for me, although perhaps unfortunately for you given the amount of writing it will produce, the Internet Archive holds scans of the Bell System Technical Journal as published by Bell Laboratories (1922-1983). The BSTJ was published by AT&T to share the impressive technical advances of its R&D operations, and it was customary for a full issue to be devoted to each major switch model. The 1ESS had its month of fame in BSTJ 43: 5 (1964), which has put quite a few miles on my printer. Perhaps the most interesting article, to the computer scientist, is “Organization of the No. 1 ESS Central Processor” by Harr, Taylor, and Ulrich.

One of the first interesting elements of the architecture described in the paper is the fact that the 1ESS computer is not a von Neumann-architecture computer. Although von Neumann or stored-program computers were the clear winners for general purpose computing in the ’60s, for reliability reasons the 1ESS actually employs the Harvard Architecture, in which instructions and data are stored completely separately. The 1ESS reads its instructions from a Program Store, and its data from the Call Store. This latter term might be confusing to the modern computer scientist who would think of something like a call stack, but remember what this machine is for: the calls stored here are literal phone calls. These two stores are connected to the Central Control, AT&T’s name for the actual processor, via two separate address and data buses.

This decision might seem a bit strange, but there’s a simple reason for it: the Program Store is similar to a PROM; that is, it’s effectively read-only. The Program Store can only be modified by physically removing the cards (called twistor memory and similar to core memory) and inserting them into a separate programming machine. This necessitates a separate writable memory, but makes the machine highly reliable: it simply cannot overwrite its instructions. As a downside of this design, the Central Control must feature completely separate registers for the two stores, which makes its design somewhat more complicated.

Another interesting element of the 1ESS architecture is that it features pipelining. Many instructions take more than one 5.5 microsecond cycle to complete, so the processor features separate instruction registers and decoders for two instructions. In the parlance of the time, one instruction is “buffered” while the other is executing, although both are really executing simultaneously.

A final hardware feature worth noting is hardware bitmasking. The Call Store uses a 23-bit word (a weird length indeed, this is a 24-bit hardware word minus a parity bit), but AT&T’s software makes heavy use of Binary-Coded Decimal (BCD) numbers where each digit is stored in 4 bits. To facilitate this, the Central Control features a Mask Circuit and Insertion Mask Circuit which can read a mask out of a register in order to perform masked reads or writes in a single instruction. That’s pretty neat!

For a little bit of extra headache, note that the Program Store uses 44-bit words with six bits of Hamming code for hardware error correction and a parity bit just to be extra safe, for an effective 37-bit word. That’s also really weird, but it leaves plenty of room for instructions to go along with a whole 21 bit address.

For the most part, the instruction set of the 1ESS is basically what we would expect. I will refer to instructions by the mnemonics used in the PROCESS III compiler-assembler developed for the machine, which the authors of the paper do as well, because numbers are hard. I hope to write a future post on PROCESS III itself, which is an interesting special-purpose programming language with macros.

1ESS instructions consist of, well, an instruction, followed by options. Instructions are often specific to a given register and are largely straightforward. The four general-purpose Call Store registers are called F, X, Y, and Z, and so the instruction to read from memory to a register has four variants: MF, MX, MY, and MZ (on the flip side, FM, XM, YM, and ZM write from register to memory). Note that I just say “memory” here rather than Program Store or Call Store – to reduce the amount of thinking that programmers have to do (always a key goal of computer design), the Harvard Architecture-nature of the machine is usually hidden from the programmer, and these instructions will read from either store depending on the address given (of course writing is only possible to the call store).

Options, on the other hand, are often rather confusing. Many instructions can be given options that add significant extra behavior – for example, setting up hardware masking, incrementing the value of the index register for the call store, or changing the value of the buffer order word register and thus jumping execution. The authors of the paper helpfully simplify this into one of the more confusing summary tables I have interacted with in my life. One of the reasons for the complexity of the tables is the limitations of the hardware: for example, setting up masking as an option is not available if the instruction needs to use the logic register (essentially part of the masking circuit) for something else.

The upside of this confusing set of options is that many higher-level logical operations can be completed in one instruction. The paper gives the example of the instruction “WX,3,Y,PL” which “Takes the Y register, increments it by 3, and places the result in the X register after first masking it.” This means:

  • WX: Indexed Word, write the output of the index register adder to register X
  • 3: Constant data option to the instruction
  • Y: Option which specifies what to use for the indexing register, in this case the contents of Y register
  • PL: Option which specifies masking, PL means to mask from the logic register, a special register usually reserved for masking use

Each of those option fields may have other meanings for other instructions, for example, the data option often specifies an address (as in the case of reading or writing to memory), the indexing register option can also specify an address that should be placed in the indexing register, and the masking option can also be used to specify other types of masking or an execution jump. Of course each option can only be used for one thing at a time. I remind you at this point that the instructions are 37 bits wide: all these options are the reason for this unusually generous width – but there are still limitations, most notably that there can only be one “data” option to instructions. This makes it critical that many instructions have one variant for each register – whenever an instruction operates on two registers, the first is specified by which instruction is used, and the second is specified as a data option.

You might find it a bit odd that this strange Indexed Word instruction (W*) is used for addition in this example. There is no direct “Add” instruction on the 1ESS computer, partially because it has two separate adders – one for the index and one for a dedicated accumulator. There are two because instructions are pipelined two at a time, and it is sometimes convenient for both to be able to add simultaneously. Arithmetic is available almost as a side-effect of other instructions. The use of the Word instruction to perform addition is very similar in spirit to the use of the LEAL instruction in x86 for multiplication: this instruction is really meant for determining a memory address to load but has the convenient property of an efficient integer multiplication implementation.

Instructions are also provided for conditional control transfer (or execution jumping) which allows for flow control and a dedicated jump instruction for returning from subroutines (with an associated dedicated register for the return address). Two of the more interesting instructions that are provided are TZRFZ and TZRFU, their names a suitable warning of their odd behavior. These are the “Rightmost One” functions, and they explain the oddly named F register – the F is short for “First one,” and these instructions determine the bit-offest of the first 1 from the right in the accumulator and place it the F register (the first resets that bit to 0, the second doesn’t). This is a pretty weird sounding instruction but was very helpful in software development for the ESS: prior to this instruction, the Accumulator is loaded with a word that represents a flag field. Using this instruction repeatedly allows the programmer to easily do something in reaction to each set flag. In context, these flags often indicate things like calls which are waiting for the machine to take an action.

Finally, the 1ESS provides interrupts, which are used predominantly for two purposes. First, some interrupts are generated by a clock at regular frequencies and are used for real-time functions like checking for dialed digits on off-hook lines. Second, interrupts are generated by a huge number of hardware fault-detection circuits and can be used to run fault-correction routines.

That came out a bit longer than I expected, but I hope it gives an interesting look at the design of the 1ESS computer. It should be clear that the basic architecture is quite specialized to the task of a phone switch, which is most obvious in the use of a Harvard architecture and the rightmost one instructions. In the future, I hope to write about the compiler and programming language developed for the 1ESS (PROCESS III), and about some of the fault-detection features of the 1ESS, including its impressive hardware consistency checking between the two redundant central processors.

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