When Changing a Computer Meant Rewiring It: Maurice Wilkes and the Control Store

Nirmal Utwani

SubscribeSign in

When Changing a Computer Meant Rewiring It: Maurice Wilkes and the Control Store<br>Week 02 of the Turing Award Series — how microprogramming turned hardware problems into software problems<br>Nirmal Utwani<br>Jun 11, 2026

Share

Week 02 of my learning series on Turing Award winners: Maurice Wilkes.<br>Before Wilkes, if you wanted to change how a computer worked, you changed the hardware. He made it a software problem instead.

My Take

Every small change required rewiring. New chips, new gates, because instructions were hardcoded into the silicon. If you wanted to add one, or fix one, you weren’t updating code. You were rebuilding the machine.<br>Wilkes changed that in 1951 with microprogramming. Instead of hardcoding operations into hardware, he introduced a recipe book stored in ROM (read only memory), called a control store. If you wanted to change how the underlying hardware behaves, don’t touch transistors and just change the recipe. That was a massive shift in reusability and portability.<br>Almost all progress over the last 70 years has been about adding more of these abstractions, each one building on the last. BIOS, operating systems, applications. All follow the same pattern. I have always dreaded on-prem compared to cloud because it seems painful to slowly push updates, bulk things, etc. Having to actually change hardware seems like 100x more complex, which was the norm before Wilkes. The thing we take for granted, that you can change behavior without touching the machine, started here.

What He Actually Did

Maurice Wilkes won the Turing Award in 1967. The citation focused on EDSAC, the first stored-program computer he built in 1949. But the idea that changed everything came two years later.<br>Microprogramming (1951)<br>Before this, every instruction a computer understood was wired directly into its hardware. The circuits for “add two numbers” were physical relays and vacuum tubes, soldered in a fixed arrangement.<br>If you wanted to add a new instruction, you had to redesign the circuitry.<br>IBM hit this wall. They’d committed the chip design before realizing they’d left out useful instructions. Too late to fix without building a new machine.<br>Wilkes’s idea: instead of wiring instruction logic into hardware, write it down in a small read-only memory called a control store.<br>Each machine instruction’s behavior is encoded as a sequence of microinstructions in ROM. Nothing is hardwired. To add a new instruction, you add new entries to that memory. No hardware change required.<br>Here’s what that looked like:<br>Before Wilkes, to execute ADD, the control unit would:<br>Route PC to memory — fixed gate path

Latch memory output into IR — fixed path

Increment PC — hardwired circuit

Decode opcode — fixed logic activating the ADD signal

Route memory to ALU — fixed wire

Route accumulator to ALU — fixed wire

Assert ALU = ADD — activates adder

Write result back — fixed feedback path

Every step permanently etched into hardware.<br>After Wilkes, the same ADD is just two microinstructions in ROM:<br>μ16: MDR ← MEM[MAR] ; load the value<br>μ17: A ← A + MDR ; add it to accumulator The hardware is generic. The specific behavior lives in ROM entries. To add ADD_TWICE that adds memory to A twice, write two new ROM entries. No hardware change.<br>Why This Mattered:<br>IBM could build a cheap slow machine and an expensive fast machine that ran the same programs. Like a Toyota and a Ferrari that both respond to the same steering wheel. Each had different hardware underneath, but the same instructions on top, each implemented in its own microcode.<br>That was the IBM System/360 in 1964, and it changed the industry. Eight models spanning a 50:1 performance range, all running the same software. Only possible because of microprogramming.<br>Modern Intel and AMD chips still work this way. When Intel patched the Spectre vulnerability in 2018, they didn’t ship new hardware. They pushed a microcode update. Changed the behavior by rewriting control store entries, not replacing chips.

The Code

I built a microprogrammed CPU simulator that mirrors Wilkes’s 1951 architecture. It has:<br>An assembler that turns assembly into machine code

A control store (68-word ROM) holding microprograms

16 machine instructions, each implemented as microcode

Run it in a REPL:<br>> LOADI 10<br>> STORE 200<br>> LOADI 25<br>> ADD 200<br>> HALT

5 instructions (26 μcycles)<br>A=35 B=0 PC=5<br>With --verbose, you see the microinstruction trace. The ADD instruction expands into six microinstructions, each controlling the data path for one clock cycle:<br>[ 3] PC=3 ADD 200<br>μ00: MAR←PC [MAR: 200 → 3]

μ01: MDR←MEM[MAR] [MDR←12488]

μ02: IR←MDR [IR: 24576 → 12488]

μ03: PC←PC+1 →DISPATCH [PC: 3 → 4]

μ16: MDR←MEM[MAR] [MDR←10]

μ17: A←A+MDR →FETCH [A: 25 → 35]That’s the Wilkes layer. One machine instruction becomes many microinstructions.<br>Full code and explanation on GitHub:...