Microcode
Control lines stored as firmware, not gates
Microcode is a technique where the control unit is a small memory (a control ROM) whose stored words are the control-line patterns for each micro-step, so the CPU's instruction set is defined by reprogrammable firmware rather than by fixed gates.
The control unit you built is hardwired: the control matrix is turned into a fixed wall of AND/OR gates. That is fast, but changing the instruction set means rewiring the chip. Microcode takes the other road: it *stores* the matrix in a small memory. Each address holds one micro-step's control-line pattern, so the control unit becomes a tiny program (the microprogram) rather than a gate network.
The matrix, but in a ROM
Picture the control matrix again: rows are micro-steps, columns are control lines. In microcode, each row is one word in a control ROM, and the bits of that word *are* the control lines. A tiny counter (the microprogram counter) steps through the ROM addresses; the current opcode picks which block of micro-steps to run. Fetch a control word, apply its bits to the datapath, advance, repeat. The control lines come out of a memory read instead of a logic gate.
The analogy: a hardwired control unit is like a mechanical music box with fixed pins; microcode is like a player piano reading a paper roll. To change the tune you swap the roll (rewrite the ROM), not the machine. This is why a microcoded CPU can be patched in the field or made to emulate an older instruction set.
Why CISC leaned on it
Complex-instruction-set (CISC) machines have many elaborate instructions, some taking dozens of micro-steps. Building all that as hardwired gates is a nightmare to design and debug. Storing it as microcode made complex instruction sets tractable, and let one microarchitecture run several instruction sets. The tradeoff is speed: a ROM read per micro-step is slower than a direct gate, which is part of why speed-focused RISC designs went back to hardwired control for their simple, uniform instructions.
Common mistakes. Microcode is not the machine code a programmer writes; it is a lower layer, the firmware that *implements* each machine instruction as a sequence of control-line settings. And microcode does not change what the control unit computes (the same levers get pulled); it only changes how the pattern is produced, by memory lookup rather than by fixed gates. Both approaches implement the identical control matrix.
Try it
Why did CISC machines favor microcode over hardwired control?
Answer
CISC instruction sets have many complex, multi-step instructions, and building all of that logic as fixed gates is hard to design, verify, and modify. Storing the control-line patterns in a ROM (microcode) makes complex instructions manageable and even patchable or replaceable in firmware, at the cost of a slower per-step memory read compared to hardwired gates.
Frequently asked
What is microcode?
Microcode is a control unit built from a small memory: each stored word holds the control-line pattern for one micro-step, so the CPU's instruction set is defined by reprogrammable firmware instead of fixed gates. A microprogram counter steps through the words to run each instruction.
What is the difference between microcode and machine code?
Machine code is the program a CPU runs, the instructions in memory. Microcode is a layer beneath it: the firmware that *implements* each machine instruction as a sequence of control-line settings. Machine code is what you write; microcode is how the hardware carries it out.
What is the difference between microcoded and hardwired control?
Both implement the same control matrix. Hardwired control turns it into fixed gates (fast, hard to change), used by RISC. Microcoded control stores it in a ROM (flexible, patchable, but a slower memory read per step), favored by complex CISC designs.
Microcode is one design choice for the control unit; the split between simple hardwired RISC and rich microcoded CISC is one of the big forks in computer architecture, as is the memory organization in von Neumann versus Harvard.
Every lesson here builds toward one thing: a working CPU, from the transistor up.
Open the free lab →