Control Unit
The control unit is the part of a processor that directs everything else: it decodes each instruction and generates the timed electrical control signals that tell the registers, the arithmetic logic unit, the caches and the memory interface what to do on each clock tick. It performs no arithmetic and holds no program data of its own; its product is coordination. When the instruction says to add two registers, it is the control unit that selects the two source registers, tells the ALU to add, enables the destination register to capture the result, and advances the program counter, all in the right order and at the right moment.
Control signals are the unit's output, and they are surprisingly concrete. They are individual wires or small groups of wires: a register-write enable, a multiplexer select that chooses where an input comes from, an ALU operation code, a memory-read or memory-write strobe, and a signal that loads a new address into the program counter. A decoder takes the opcode bits of an instruction word and expands them into the right pattern of these signals; a sequencer or state machine steps through the phases of the instruction cycle, so that fetching, decoding, executing and writing back happen in order. Seen this way the control unit is a finite state machine whose inputs are the instruction bits, the status flags and the clock, and whose outputs are the control lines.
There are two classic ways to build a control unit, and the history of both is instructive. A hardwired control unit implements the decoding and sequencing as fixed logic gates, which makes it fast and compact, and is typical of simple and RISC-style designs. A microprogrammed control unit, proposed by Maurice Wilkes in 1951 at Cambridge, instead stores each machine instruction as a short sequence of micro-instructions in a small internal memory, the control store, so that a complicated instruction set can be implemented by writing microcode rather than designing new circuitry. IBM's System/360 family of 1964 used microcode to run one instruction set across models of very different speed, and microcode made rich instruction sets such as the VAX and x86 practical.
Modern processors blend the two approaches and make the control problem far harder. Today's x86 CPUs decode complex instructions into simpler internal micro-operations, often hardwired for common cases and microcoded for rare, complex ones, and then schedule those across several execution units. A pipelined core needs control logic to detect hazards, such as an instruction needing a result that has not yet been produced, and to stall, forward results or flush the pipeline after a mispredicted branch. Interrupts and exceptions also pass through it: when a device signals or a program faults, the control logic saves the current position and redirects execution to a handler. Microcode can be patched, and operating systems and firmware load vendor microcode updates at boot to correct processor errata or to mitigate security flaws such as those disclosed in 2018.
Several common confusions are worth avoiding. The control unit does not process the program's data, which is the ALU's work, and it is not a visible separate chip: in a modern processor it is distributed through the core, intertwined with fetch, decode, scheduling and retirement logic. It is also not the same as the operating system, which is software that decides which program runs, whereas the control unit decides, cycle by cycle, which wires switch to carry out one instruction. For programmers, its influence shows up in performance: why branches that are hard to predict cost cycles, why some instructions take many cycles because they are microcoded, and why the same instruction set can run on chips with very different internal control designs.
Read the control unit as the conductor of the processor: it plays no instrument itself, but by reading each instruction and cueing every other part at the right instant it turns a stored list of operations into actual computation.