microprogrammed control

Here are two ways to build the control unit. You could hand-wire a tangle of logic gates that, given an opcode, lights up the right control signals — fast, but rigid. Or you could keep the control signals in a tiny internal lookup memory and have each machine instruction trigger a little sequence of entries from it, like a player piano reading a punched roll. The second way is microprogrammed control: the control logic is itself a small program (the microcode) stored in memory.

In a microprogrammed multi-cycle CPU, executing one machine instruction means running through several microinstructions, each of which is essentially one row of control-signal values (one cycle's worth of switch settings) plus a pointer to the next microinstruction. The opcode selects where in the microcode to start; the machine then steps through micro-step after micro-step until the instruction is done. So 'load' becomes a short script: compute the address, read memory, write the register — each line of the script is a microinstruction.

The honest comparison: microprogramming made complex instruction sets (CISC) easier to build and easier to fix or extend — you could change behavior by rewriting the microcode rather than rewiring silicon, and historically vendors shipped microcode patches. The cost is speed: looking up microinstructions from memory each cycle is slower than dedicated gates. That is one reason RISC machines favored simpler instructions implementable with fast hardwired control. Modern high-performance x86 chips actually blend both: most instructions are hardwired, but rare or complex ones still fall back to microcode, and microcode updates remain how vendors patch CPU bugs in the field.