Registers, the ALU and the Control Unit

You already know the CPU spins endlessly through the fetch–decode–execute cycle. But what actually does the fetching, the decoding and the executing? Inside that postage-stamp of silicon there is no single "brain cell" — there is a small team of specialised parts, each with one job, wired together so tightly that a value can hop from one to the next in a fraction of a nanosecond.

At A-level you are expected to know this team by name and to say exactly what each member does during a single instruction. There are three kinds of part:

the Arithmetic Logic Unit (ALU) — the part that actually calculates and compares;
the Control Unit (CU) — the part that decodes each instruction and conducts everything else by sending timed control signals;
a handful of registers — tiny, ultra-fast stores that hold the exact values the CPU is working with this instant: the PC, MAR, MDR, CIR and ACC.

Meet each one, then watch them pass a single instruction between them, hand to hand, all the way round one turn of the cycle.

The Arithmetic Logic Unit — the calculator

The ALU is the only part of the CPU that does real arithmetic and logic. It is a bundle of digital circuits that takes one or two binary inputs and produces a result:

Arithmetic — add, subtract, and (built from those) multiply, and shift bits left or right. A left shift by one, for example, doubles a binary number, just as adding a 0 on the end multiplies a decimal number by ten.
Logic — bitwise \text{AND}, \text{OR}, \text{NOT} and \text{XOR}, and comparisons such as "is this equal to that?" or "is this bigger?". Comparison is how every \texttt{if} and every loop condition is ultimately decided.

The ALU works hand-in-glove with one special register, the accumulator (ACC), which holds the value the ALU is currently working on and catches the result that drops out. The ALU itself has no memory — it is pure combinational logic. Feed it two numbers and an operation and out comes an answer; the moment the inputs change, so does the output. Anything worth keeping has to be copied straight into a register.

The ALU is really a stack of tiny circuits sitting side by side — an adder, an AND gate array, an OR gate array, a comparator, and so on — all fed the same two inputs at once. A group of control lines called the function select then acts like a multiplexer, choosing which circuit's output to let through. So the ALU computes several possible answers in parallel every clock tick and simply picks the one the current instruction asked for. Subtraction, cleverly, is just addition in disguise: to compute a - b the ALU adds a to the two's-complement negative of b, so no separate subtractor is needed at all.

The Control Unit — the conductor

If the ALU is the calculator, the Control Unit is the conductor of the whole orchestra. It does not calculate anything itself. Instead it makes sure every other part acts at exactly the right moment, in the right order. Its jobs are:

Decode — take the instruction now sitting in the CIR, split it into its opcode (which operation) and its operand (which data or address), and work out what needs to happen.
Send control signals — fire the precise electrical signals along the control bus and to the internal registers, opening and closing the "gates" that let data flow from one place to another: copy the PC into the MAR now; tell memory to read; latch the data into the MDR; tell the ALU to add.
Keep time — synchronise all of this to the CPU's clock, so that each micro-step happens on its own tick and nothing races ahead of the data it depends on.
Manage flow — orchestrate the entire fetch–decode–execute cycle, and handle jumps, branches and interrupts by changing what happens next.

Think of the CU as reading each instruction and then pulling a rapid, carefully-timed sequence of levers. It never touches the data's value — it only controls where the data goes and when.

The registers — five stores you must know

A register is a single, extremely fast store inside the CPU that holds one value — typically one word (e.g. 32 or 64 bits). Registers are far faster than main memory because they sit right next to the ALU and control unit, so the CPU keeps the values it needs this instruction in them. Five are named on the A-level specification, and each has one precise job:

Program Counter (PC) — holds the memory address of the next instruction to be fetched. It is incremented during every fetch so the CPU steps through the program in order (a jump instruction overwrites it).
Memory Address Register (MAR) — holds the address of the memory location the CPU is about to read from or write to. Whatever address the CPU wants to touch in memory goes into the MAR first.
Memory Data Register (MDR) — holds the data or instruction just read from, or about to be written to, that memory location. It is the CPU's doorway for everything travelling to and from memory (sometimes called the MBR, memory buffer register).
Current Instruction Register (CIR) — holds the instruction currently being decoded and executed, so the control unit can read its opcode and operand.
Accumulator (ACC) — holds the data being worked on by the ALU and catches the result of a calculation or comparison.

Notice how they pair up with the buses. The MAR feeds the address bus (addresses only, one-way out to memory); the MDR sits on the data bus (data and instructions, both ways). The PC keeps our place in the program; the CIR holds the instruction under the control unit's nose; the ACC works alongside the ALU.

How they fit together

Here is the whole team as a block diagram: the ALU and control unit, the five registers, and main memory reached across the address, data and control buses. Step through it to see each part appear.

Everything the CPU does with memory goes through the MAR/MDR pair — the MAR says where, the MDR carries what. Every calculation goes through the ALU/ACC pair. And the control unit quietly pulls the strings on all of it, driven by whatever instruction currently sits in the CIR.

Tracing one instruction, register by register

This is the part examiners love: describe the fetch–decode–execute cycle in terms of the registers. Suppose the PC holds address 100; the instruction stored there is "ADD the value at address 200"; and memory location 200 holds the number 5. Step through and watch each register's value change, one micro-operation at a time.

Read the whole trace as one sentence: the MAR keeps saying where, the MDR keeps carrying what, the PC quietly moves on to the next line, the CIR holds the instruction being obeyed, and the ACC collects the answer from the ALU. That is the cycle, told through the registers.

It looks odd to move the PC on to 101 before we have even finished with the instruction at 100. But it is deliberate: the PC's only job is to name the next instruction, and the cleanest moment to update it is the instant we have used its current value to load the MAR. By the time we reach execute, the PC is already correctly pointing at what comes next — so if the instruction turns out to be a jump, execute can simply overwrite the PC with the jump's target address, and the cycle carries on from there without any special case. Increment early, and branching becomes just "put a different number in the PC".

The single most common exam slip here is mixing up what each register holds. Pin these down and you will not lose the marks:

The MAR holds an address — a location number, like "200". It never holds the value stored there.
The MDR holds the data (or instruction) — the actual value living at that location, like "5". It is the contents, not the address.
The PC holds the address of the next instruction — not the current one, and not a data value. (The instruction being obeyed right now lives in the CIR.)

A neat memory hook: MAR = "where" (Address), MDR = "what" (Data). And a second trap: the control unit does not do arithmetic — it only decodes and directs. All the adding, subtracting and comparing is the ALU's job. Say "the control unit added the numbers" in an exam and you will lose the mark.