The processor: fetch, decode, execute

You now have two of the three things a computer needs. Gates can compute — a stack of them adds two numbers (item 5). Memory can hold — millions of cells, each storing a value you can fetch by its address (item 6). But a pile of gates next to a box of memory just sits there. Nothing happens. What makes the machine go — on its own, in the right order, without anyone reaching in to push the next button?

The answer is a loop. One small, relentless, stupid loop, run so fast it looks like thought.

The thing that’s missing: order, and a heartbeat

Picture the memory from item 6 as a numbered list of slots: line 0, line 1, line 2, and so on. We put a list of instructions in those slots — “load this number,” “add that one,” “store the result.” Now we need something that walks down the list, one line at a time, and actually carries each instruction out.

That something needs two parts we haven’t met yet. First, a clock — not a clock that tells the time, but a metronome. It ticks, billions of times a second, and every tick says the same thing: next. Second, a tiny piece of memory called the program counter — a single register that holds one number: the address of the instruction to do next. Line 0, then line 1, then line 2. The program counter is the machine’s finger on the list.

That’s the whole cast. Memory holds the instructions. The program counter points at the current one. The clock says when to move. And a small part called the control unit does the actual work of reading each instruction and making it happen. There’s no manager, no plan, no understanding. Just a finger, a metronome, and a list.

The loop: fetch, decode, execute

Every tick of the clock, the machine does the same three steps, in the same order, forever.

Fetch. Read the program counter to get an address. Go to that line in memory. Pull out the instruction sitting there. That’s it — fetch just means “grab the next instruction off the list.”

Decode. The instruction is a pattern of bits (it’s all bits — item 1). The control unit looks at that pattern and works out what it’s being told to do. Is this an add? A load from memory? A store? Decode means “read the instruction and figure out which action it names.”

Execute. Do it. If the instruction says add, the control unit hands the numbers to the adder from item 5 and keeps the answer. If it says store, it writes a value back to a memory cell. The actual doing.

Then one more small move: bump the program counter to the next line, so the finger points one further down. And the clock ticks, and it all happens again. Fetch, decode, execute. Fetch, decode, execute. That four-part beat is the heart of every computer ever built. When a chip is described as “three gigahertz,” that number is just how many times this loop runs per second — three billion.

A worked example: adding by walking a list

Let’s run a real program. Suppose memory holds a short list, and there’s one working register — call it the accumulator — that holds the number we’re currently working on. The program:

• Line 0: LOAD 5 — put the number 5 into the accumulator.
• Line 1: ADD 3 — add 3 to whatever’s in the accumulator.
• Line 2: STORE — write the accumulator’s value out to memory.
• Line 3: HALT — stop.

The program counter starts at 0. Watch it go.

Tick one. Fetch: the program counter says 0, so grab line 0 — LOAD 5. Decode: this is a load. Execute: the accumulator becomes 5. Bump the counter to 1.

Tick two. Fetch line 1 — ADD 3. Decode: an add. Execute: hand 5 and 3 to the adder; it returns 8; the accumulator is now 8. Bump the counter to 2.

Tick three. Fetch line 2 — STORE. Decode: a store. Execute: write 8 out to a memory cell. Bump the counter to 3.

Tick four. Fetch line 3 — HALT. Decode: stop. Execute: the loop ends.

Four ticks. The accumulator climbed 5 → 8, and the answer landed in memory. Nothing in there was clever. The machine never knew it was “doing arithmetic” or what the 8 was for. It read a line, did the one thing the line named, moved its finger, and read the next. That is the entire trick.

There is no one inside

It’s tempting to imagine a little operator in the chip, reading the program and understanding the goal. There isn’t. “Running a program” is this dumb loop, repeated faster than you can picture, over a list of instructions someone wrote down in advance. The processor only ever does the next thing on the list. It has no idea what the list is for.

That’s worth sitting with. A computer playing music, guiding a plane, or holding a conversation is doing the same fetch-decode-execute it does to add 5 and 3 — the same three steps, just more of them, over a longer list. All the apparent purpose lives in the order of the instructions, not in the machine. The machine supplies speed and obedience; the meaning is borrowed entirely from the list, and from whoever arranged it. Knowing that doesn’t make the device less impressive. It moves the wonder to where it belongs: not in a clever box, but in how far you can get by doing the simplest possible thing, in order, three billion times a second.