DJW26 EDSAC-2 Portfolio - A First Study - Microcode

PAGE UNDER CONSTRUCTION 3Q2026

EDSAC-2 was arguably the world's first operational microcoded machine: certainly the first 'full-scale' machine. Actually, the documentation for EDSAC-1.5 is also in the DJW26 portfolio but I've not looked at it yet. Perhaps that was the first one?

EDSAC-2 ran each instruction by executing a sequence of micro-orders for each user instruction. These also implemented the exception and interupt mechanisms and the write-back generally necessary after a primary store read, since ferrite core has destructive read-out.

I am not sure whether we should call this a VLIW (very-long instruction word) system? It was horizontal? not vertical? since it has unary command encoding, with no subsequent binary-to-unary decoding from packed fields.

Microcode Ideas and Precursors

EDSAC 1.5

However, this is likely a description of EDSAC 1.5, since EDSAC-2's ROM was much larger. This is corrected here UPROG.

Wilkes' Proposals

Wilkes had described techniques for micro-coding in Wilkes+Stringer53.

Figure 1 from Wilkes+Stringer 1952 'Micro-programming and the design of the control circuits in an electronic digital computer.

He went on to advocate the "Best Way" for designing microcode in MV Wilkes:: "THE BEST WAY TO DESIGN CALCULATING AN AUTOMATIC MACHINE" Volume 14 Part 2 pp 182-184 in THE CHARLES BABBAGE INSTITUTE REPRINT SERIES FOR THE History Of Computing. 1951. Reprinted in the Anals of the History of Computing .

Similar image given from Wilkes' paper at the Babbage Institute.

But, the approach used in EDSAC-2 differed fairly radically from this 'Best Way' approach. Although he had pointed out that " quote needed " technology changes and a suitable mix of ferrite and diode ... He says he was asked to 'open up discussion', mentions pluggable microcode ROMs and finished with considering user-programmable microcode.

Nonetheless, the controller design used in EDSAC-2, as finally disclosed in Wilkes+Gill, is not really covered in his 'Best Way' review!

EDSAC 2 Microcode Implementation

The microcode program counter needs a reset point (two are used I think owing to the clear-to-ones option - I will check), and it needs to advance from one micro-order to another, sometimes making a multi-way branch. As Wilkes suggested, optimsing the multi-way branch for order dispatch is a key consideration, as is selecting the balance between ferrite core and semiconductor diodes for the switching mechanics.

The method used in EDSAC-2 was reported in Wilkes+Renwick+Wheeler <.V. Wilkes, W. Renwick, and D.J. Wheeler, “The Design of the Control Unit of an Electronic Digital Computer,” Proc. IEE, Vol. 105B, 1958, pp. 121-128.

Figure 10 from Wilkes+Gill (an accurate rendition of the EDSAC-2 solution).

The key text from Wilkes+Gill that explains the instruction dispatch mechanics.

Moreover, the four-quadrant binary decode is exploited in the micro-code to distinguish between 'modifier' and non-modifier orders.

EDSAC 2 Microcode Implementation

One instance (how many were there?) of the Microcode ROM

Unlike modern vertical microcode, the EDSAC-2 control matrix features no downstream binary-to-unary decoding. The 65 or so control lines operate entirely in parallel. A large number of these lines (or micro-orders) control transfers between architecural registers in the arithmetic, address and BIU units (CT1 through CT3). It is perfectly possibly to cause a bus fight by commanding more than one word is transferred to the same destination at once. These units are implemented with Resistor-Valve Logic (RVL) which is what I might call the valve equivalent of resistor-transistor logic. This is inherently functions as a wired-OR, so activating multiple source lines simultaneously would causes a benign bus overlap. Avoiding this is one of the static side-conditions for the micro-code to be well-formed. Other conditions (mentioned later) relateto settling delays and shoot-through.

Each micro-order has a name and an address. The names broadly corresponded to the function. For instance, names starting with 'I' implement instruction fetch and those starting with 'J' implement jumps and branches. The address was two-dimensional, locating the micro-order in a 32-by-32 virtual grid. Each micro-order was held in the hardwired microcode ROM that was implemented with ferrite cores. The cores were placed in plastic holders, with up to 16 cores per holder and the holders being in something like an 8-by-8 grid. There could be up to four cores at a given address, owing to predicated operation (see below).

Each core implements a four-input AND gate whose output feeds some number of micro-command sense lines. The input terms and the output sense wires were all threaded through the core (number of turns on the sense wires was?). The microcode ROM data is represented by the physical routing of the sense wires thorough just the cores that should trigger it.

An EDSAC-2 microcode core holder or frame">

A micro-order program counter of ten bits is implement across several instances of CT6.

The micro-order program counter addresses precisely one micro-order location. There are 1024 possible addresses and there is a one-to-one mapping between micro-order names and addresses. But more than one micro-order is often stored under a given name and address, with disjoint guarding predicates. The one whose predicate holds provides the next micro-order address. The successor is activated on the next clock pulse of the master clock. (Unlike EDSAC-1, EDSAC-2 was fully static and could be single-stepped one micro-order at a time, with the large 'engineer's display panel' of neon indicators showing the bits in all the registers and micro-architectural flip-flops.)

Two of the input wires threaded through a core correspond to the row and column of the core's address. Up to two further 'conditional bias' wires provide conditional operation. Conditional operation is needed for user-level IF-THEN logic required for conditional branch orders. But it is also needed for microcode level loops, such as long multiplication and floating-point normalisation steps. Finally, conditional operation also supports something akin to subroutine calling at the microcode level.

These microcoded 'subroutines' are not implemented with a saved return address. They are just a means of invoked a shared common sequence of operations from more than one call site. This is achieved with the provision of so-called 'Y' flip-flops, that the microcode can freely set or clear before jumping to a shared sequence. The sequence is terminated with jumps conditional on the 'Y' flops so that the next step accords with the 'callers' intentions.

Example Instruction: Multiply

EDSAC 2 Microcode Example - Fixed-point Multiply. As scanned.

EDSAC 2 Microcode Example - Fixed-point Multiply. As OCR'd, corrected and hard-annotated.

Summary of Microcode Predicates

Summary of Control Wires or Micro Commands

The following micro-command control wires are used in the microcode. As mentioned above, these are 'horizontal' control wires that are directly driven sensed from the threading of a sense wire through a ferrite core in the control matrix and they are not subsequently unpacked in any way, such as with binary-to-unary decoders.

There are 65 of these, if I have accounted correctly.

The maximum number of core sense wire threaded on a core is ... about 5 of these plus a further two to select the successor micro-instruction.

DJG status: The wiring and semantics for the marjority of them is now understood.

Activate Constan Micro-Commandt

AC - activate constant - loads a pre-selected hardwired codes into the core store date register. The value is commonly (always) then transferred into RX using STX. RX is normally (always?) cleared first, so the fact that STX used a bitwise-OR into RX is (generally?) immaterial.

Z13?=89<<20:=512<<20/MDRX;=0/Z12;=0/Z13;=0/Z14;=0/Z15

Activate constant table of values and Zflop reset ...

A table of constant values for AC does not appear to be present in DJW26. It was relatively easy to work out the Z-flop values present at each use site, but only some of the associated constants have been determined so far.

TABLE OF AC CONSTANTS ...

Micro-code Validation Steps

Unlike modern vertical microcode, the EDSAC-2 control matrix features no downstream binary-to-unary decoding. The 100+ control lines operate entirely in parallel. Because the underlying Resistor-Valve Logic (RVL) inherently functions as a wired-OR, activating multiple source lines simultaneously does not result in a structural decoder error, but merely causes a benign bus overlap. To reflect this unencoded, direct-drive architecture, the individual control units of the micro-instruction word are referred to here as gate wires. A large number of these are 'transfer pulses' which cause the transfer of a word from one register to another, with no distinction between architectural and micro-architectural registers.

Basic validation conditions:

• Micro-order names and addresses validation There should be no repeated names or addresses, except where predicates differentiate. Correct (systematic) correspondence between micro-order names and addresses.

• No bus fights

  While the underlying Resistor-Valve Logic (RVL) safely resolves concurrent bus drives via a wired-OR, the microcode was hand-crafted to avoid bus contention. The validator enforces a mutual exclusion (mutex) constraint on all gate wires sharing a common destination bus, confirming that no microinstruction accidentally commands multiple sources to drive the bus at once.

• No combinational path (or shoot-through)

  No path should exist generated by simultaneously enabling the leader (master) and follower (slave) transparent latches that we would now recognise as the essence of an edge-triggered transfer (or dual-phase non-overlapping clock). In modern synchronous design, this would violate the non-overlapping clock phase constraint and cause a hold-time failure.

• Unreachable micro-orders

  A control-graph trace ...

• Deadend ciphons

  Apart from the halt and stop-report states, every micro-order should have a successor, regardless of the predicate (sense wire) combinations.

• Maximum Fanout

  The number of micro-commands threaded by a core should be bounded for physical realisation (getting the wires through) and noise margins.

• Settling Delay for Multi-cycle Paths

  The result from an addition or other slower operation should not be used in the next micro-order.

• Write back

  A read from primary storage should be written back afterwards unless explicitly due to be modified.