Inside a CPU

A CPU is not one thing that runs instructions. It is a front end that fetches and decodes them, a set of execution units that do the work, a register file they read and write, and caches feeding all of it — with most of the silicon spent on keeping those units busy rather than on the arithmetic itself.

Registers are the only storage the ALU can read directly, they are the fastest thing in the machine by a wide margin, and an ISA typically exposes a couple of dozen of them. Everything a compiler does with local variables is an attempt to keep the right values in that tiny space.

The arithmetic logic unit performs the operations that source-level arithmetic compiles into, sets the flags that comparisons and branches depend on, and — crucially — does not treat all arithmetic as equal. Add and XOR are nearly free; divide is not.

Something has to read a decoded instruction and tell the rest of the core what to do with it — which register file ports to open, which ALU operation to select, whether to write memory. That something is the control unit, and it is the least visible and most quietly consequential block in the machine.

Registers feed the ALU, the ALU feeds registers back, and a separate route runs from the register file through address calculation to the data cache and back. That loop, plus the memory path hanging off it, is the datapath — and its shape explains why instruction sets look the way they do.

One register holds the address of the next instruction. Incrementing it is trivial; redirecting it is the single most disruptive thing that can happen to a modern CPU, because everything the front end fetched behind the redirect turns out to have been the wrong guess.

A clock cycle is the machine's unit of time, and clock rate is one of three factors in how long a program takes — the other two being how many instructions it runs and how many cycles each takes. Comparing CPUs by gigahertz alone ignores two thirds of the equation and all of the memory system.