13The Fetch–Execute Loop

Last chapter we taught the machine to read a single byte as a command. It split the byte into an opcode and an operand, fed the halves to different parts of the datapath, and we watched a single byte load register A from memory. It worked. But look closely at who ran it: you did. You picked the instruction. You set the operand. You flipped the enables in order. The machine was a beautifully built puppet, and your hand was inside it. Now I want to take my hand out — and yours. Because a program isn't one instruction. It's a list of them sitting in RAM. Running a list means answering two questions the machine can't answer yet: which instruction am I on right now, and how do I get to the next one by myself? That whole leap — from "a pile of logic that does one thing when poked" to "a computer running your code" — is hidden in those two questions. The answer is one small register that holds an address and knows how to count. It's called the program counter. It drives one tight, tireless cycle: fetch the instruction it points at, advance to the next, execute what it fetched, then go around again. That loop, spinning on its own, is the difference between a machine and a computer.

01Where am I? The program counter

Here's the machine as we left it. Every block sits on one shared bus, along with the two new registers from last chapter: the MAR, which names a memory cell, and the IR, which catches the instruction. Take one more slow look, because we're about to spot the single thing it's missing.

Now the reframing that starts the whole chapter. A program is not one instruction. It's a column of them, sitting in consecutive cells of the same RAM that holds your data. Address 0 holds the first command, address 1 the next, and so on down. The cut is the one we agreed last chapter, and it never moves: the top four bits of a byte are the opcode, the bottom four are the operand. Try it on 01001000. Read it as a number and it's 72 — one 64, one 8. Cut it in half and it's a store into address 8. Nothing in the byte changed. Here is that RAM strip again. Picture the top few rows not as numbers but as an ordered to-do list the machine will work through, top to bottom.

To work through a list in order, you need a finger on your place. Without one, the machine finishes line 4 and has no idea that line 5 is next. So we add exactly that: a small register whose only job is to hold the address of the instruction we're on. It's called the program counter, or PC for short. It's nothing more exotic than a register wired to point into RAM. Watch it aim at a row.

A finger that only ever points at line 0 is useless, though. The PC has to move. After fetching the instruction at address 3, it must become 4, then 5, then 6, marching forward one step at a time. And "add one to a register, over and over" is a machine you already built. Back then, we fed a register's own value plus one back into its input on every clock edge. That's a binary counter. Let it run.

The plan never lets us wave at a magic "+1 block," so let's open the increment up and see the arithmetic actually happen. Adding one to a binary number is the simplest possible add. Flip the lowest bit. If it was a 1, it rolls over to 0 and hands a carry up to the next bit — exactly the roll-over you saw an odometer do. Step a single increment and watch the carry ripple left through the wires.

Now the itch, before it turns into a nag. This machine already has an adder — the ALU you built chapters ago. So why does the PC get a second one? Look at what the ALU is actually wired to: register A and register B. A is where the program's running total lives. To borrow the ALU for a +1, you'd have to drop the PC's address into A, flattening the total the program is halfway through computing, then add one, then put the address back, then somehow restore the total you just wrecked. And you'd pay that on every single fetch, because every instruction fetches. A handful of gates dedicated to +1 is cheaper than all that traffic. Better than cheap: the PC steps forward on its own, without disturbing a single bit the program cares about. Real CPUs make exactly this trade.

So the PC is a real, honest circuit: a register plus an increment that ripples carries, latching the next address on each tick. Nothing borrowed, nothing assumed. Now we have the finger, and we have the "move to the next line." Time to use them.

02The fetch: pulling the next command

Here is the heartbeat of every computer ever made, drawn as a loop. The PC points at a cell, and fetch pulls that cell's byte into the IR. The PC advances to the next cell. The machine executes the instruction it just fetched. And then — this is the part that makes it a computer — it goes straight back to fetch and does it all again, forever, with no one watching. Trace the arrows.

Before we break the fetch into ticks, do it yourself. Take ADD. Write down the moves the machine has to make to get that byte out of RAM and into the IR — you have the PC, the MAR, the bus, and last chapter's habit of naming a cell before you read it. Now write the same list for SUB. Now for JMP, an instruction I haven't taught you yet. Write its fetch anyway. Your gut should be objecting right about now: these are wildly different verbs, so surely what you're fetching changes how you fetch it. Look at the three lists you just wrote before you read on.

They're the same list. Not similar. Identical, all three, and you wrote them that way yourself. Now here's why it had to come out like that. Sit at the first tick and ask what the machine actually knows. The instruction is still in RAM. The IR is empty. The opcode — the four bits that would say ADD or JMP or HALT — has not been read yet, because reading it is the job we're in the middle of. So the fetch cannot depend on the opcode. You cannot branch on a byte you haven't looked at. That isn't a design choice anyone made. It's the order of events, and it leaves no room for cleverness. It's why you could write JMP's fetch without knowing what JMP does. And it's the reason the whole thing can close into a loop: if every lap opens with the same two moves, nobody ever has to tell the machine how to start a lap. Let's break that fetch into its actual clock ticks.

Two beats, and they're worth naming precisely — in the control lines, because those are the only words the hardware understands. On the first tick, the PC drives its address onto the bus and the MAR latches it. That's two lines high: CO (counter out) and MI (MAR in). Now RAM knows which cell we want. On the second tick, RAM drives that cell's byte onto the bus, the IR latches it — and, in the very same tick, the PC increments. Three lines: RO (RAM out), II (IR in), and CE (counter enable, the increment itself). So the fetch costs exactly two clock cycles. When it's done, the instruction is sitting in the IR and the PC is already aimed at the next line, ready for the round after this one. But hold on. If the PC is changing on the very beat RAM is being read, doesn't the address shift under RAM's feet? That's the right question, and it deserves a real answer rather than a shrug.

So let's answer that, and the answer is already sitting in the machine. Where does RAM's address actually come from? The MAR. Not the PC. The MAR latched that address a full beat ago and has been holding it steady ever since — that is the whole reason the MAR exists, and it's why the fetch needs a first beat at all. The PC could catch fire on the second tick and RAM would never notice. Now the deeper half. Every register here is edge-triggered: it samples what's on its input before the edge arrives, and commits the new value after. So on that second tick the incrementer is looking at the PC's old value, and the new address only exists once the edge has passed. A value cannot reach backwards into the beat that made it. That's not a trick. It's the definition of edge-triggered, straight from the register chapter — the same discipline that lets a bus full of gates march in lockstep. The machine now knows what to do and where it'll go afterward. All that's left is to actually do it.

03The execute: a handful of verbs

With the fetch handled, "executing a program" comes down to a small vocabulary of things an instruction can do once it's in the IR. Our toy speaks just a handful of them. Every one is a short sequence of the same bus moves you already know — enable a source, latch a destination — stacked on top of the two-cycle fetch. Here's the machine's whole instruction set on one card — the five straight-line verbs, plus the two that bend and end the march: the opcode, the mnemonic we call it, and what it does.

A note before we run one, because it explains half the table. The arithmetic instructions — ADD and SUB — don't name two operands. They name one. The other is implicit: a scratch register, call it B, that the ALU always uses as its second input. Register A is where the running total lives. B is the value being folded in. Recall the ALU with its two dedicated operand registers hanging off it.

So ADD 9 means: fetch the number living at address 9 into B, then set A ← A + B. Count what that costs, in beats you've already watched. Two for the fetch: PC→MAR, then RAM→IR with the PC stepping. Then the operand has to name its cell before RAM can be read — beat three: operand→MAR. RAM hands the byte to B: beat four. The ALU folds B into A: beat five. Now go down the card and try to beat that. LDI drops its operand straight into A. One move, done. OUT copies A to the display. One move, done. Neither needs a third execute beat. ADD does — it's the instruction that needs the machine's full allotment of steps. So the budget is five clock cycles: two for the fetch, and up to three for the execute. Not because five is special, but because a lap has to be long enough for the hungriest verb on the card. That's precisely why the budget is five. Step through all five and watch the PC advance during the fetch, then the operand do its work.

Five beats: PC→MAR, then RAM→IR with PC++ (the fetch), then operand→MAR, RAM→B, and finally A+B→A (the execute). Now the mirror image. SUB is the same shape — load B, then feed the ALU — but with the ALU told to subtract. Here the earlier chapters pay a quiet dividend: the machine has no subtractor. It computes A − B as A + (−B). It builds −B with the two's-complement invert-and-add-one trick, so the very same adder that does ADD also does SUB. That's also why "0 − 1" lands cleanly on −1 (all ones) instead of breaking. Watch subtraction happen with no subtractor in sight.

Adding and subtracting are pointless if you can't keep the result. STA — store A — is two moves and no new parts. First the IR's operand goes onto the bus and the MAR latches it, naming the cell. Then A pushes its value onto the bus and RAM latches it into that cell. That's it. And if it feels familiar, it should: it's LDA from last chapter, the load we ran to pull a byte out of memory, with the traffic pointed the other way. Same three parts, same two beats, opposite direction. Follow A's value flowing into memory.

Two more and the set is complete. LDI — load immediate — is the quickest instruction of all. The operand nibble isn't an address to look up. It's the value itself, loaded straight into A with no trip to RAM. "Immediate" means the data is right there in the instruction. It's how you get a starting number into the machine.

And OUT — the machine finally showing its work. It copies A into an output register wired to a display. A number the CPU has been shuffling in silence becomes something a human can read. Here's the display itself — the lookup table that turns a number into lit bars.

That's the entire straight-line vocabulary: load a constant, add, subtract, store, show. Feed the machine a column of these and it will march down them — fetch, execute, fetch, execute — computing as it goes. But "march down them" is exactly the problem. A straight run only goes one way: down. Off the bottom of memory and into gibberish. To write a real program, the machine has to be able to break the march.

04Bending the march: JMP and HALT

Everything so far assumes the PC only ever does one thing: count up by one. But the PC is a register, and a register can be written to. Before you read on, answer this. Every register in this machine loads from the bus the instant its load-enable goes high. Nobody ever said the PC was different. So what happens if a byte lands in the PC by the same route a byte lands in A? What if an instruction, instead of touching A or RAM, reached over and wrote a brand-new address straight into the PC? Then the next fetch wouldn't grab the following line. It would grab whatever line that address names. That's a jump. Now lay it beside its twin, in the lines. STA: A talks (AO), RAM listens (RI). JMP: the IR's operand talks (IO), the PC listens (J). One out-enable, one load-enable, both times. The only difference is which load-enable went high. Control flow isn't a new power. It's a store with a different destination. Watch the operand overwrite the PC.

So JMP 3 means "put 3 into the PC," and the very next fetch pulls the instruction at address 3. The machine has teleported. Put a JMP at the bottom of a block, pointing back to the top, and you get something the straight run could never do: a loop that runs the same instructions over and over. Here's the PC counting along on its own, wrapping 1111 back to 0000 when it runs off the end — and a JMP button that slams it to any address you choose, mid-stride.

That single power — write the PC — is what turns a to-do list into a program with structure. But a loop that JMPs back forever now has the opposite problem: it never stops. We need a way to say "we're done." Recall the clock — the tireless square wave that drives every tick of every fetch. We're not taking it on faith any more. We built the real thing last chapter: a ring of inverters wired output back to input, a loop that can't settle, chasing its own tail forever. Out comes the square wave. That's what we're about to go after.

If the loop only runs while the clock is ticking, then stopping the machine is as blunt as it sounds: stop the clock. HALT does exactly that. It drops a "run" line that's ANDed with the clock. The ticks stop reaching the registers, and the whole machine freezes right where it is, mid-address, holding its last state. No dramatic shutdown. The beat just stops. Flip the run line and watch the ticks die.

With JMP to bend the march and HALT to end it, the instruction set is finally expressive enough to run a real, finite program from start to a deliberate stop.

05The loop, running on its own

Let's watch the whole thing turn with no hand on the controls. Here is a tiny program in Python's clothing — an interpreter for our straight-line instruction set. It runs a short routine: load a number, add another, show the result, and halt. It fetches, advances the PC, executes, and repeats, exactly as the silicon would, and the trace beside it shows every beat as it lands.

pc = 0
while True:
    mar = pc                 # beat 1: PC→MAR
    ir = mem[mar]            # beat 2: RAM→IR …
    pc = (pc + 1) & 0xF      # … and PC++, same edge
    op, n = ir >> 4, ir & 15  # 4-bit op, 4-bit operand
    run(op, n)               # beats 3-5 (A stays 8-bit: & 255)
    if op == HALT:
        break

Read the trace and you're reading the machine's inner monologue: I'm at line 0, the instruction there is LDI 2, do it, now I'm at line 1… That's the fetch–execute loop, spinning by itself. That is a computer. Not a metaphor for one, not "like" one — the real thing, in miniature: a program counter walking through RAM, a fetch that never varies, a handful of verbs, and a jump that lets it double back.

That's Chapter 13. The machine runs a program with one tireless cycle. The program counter points at a cell, and fetch pulls it into the IR. The PC advances (a real binary counter, carries and all). And the instruction executes in up to three more bus moves — a fixed five-tick lap, sized for the hungriest verb on the card. We built the straight-line verbs — LDI, ADD, SUB, STA, OUT. We saw JMP reveal itself as nothing but a store aimed at the PC. And we stopped the whole thing dead with HALT by starving the clock. But sit with what this loop still can't do. It marches, and with JMP it can loop forever — but it cannot choose. Every JMP is unconditional: it always jumps, no matter what. A real program needs to loop while a counter is nonzero, to stop when a total is reached, to branch on what it just computed. For that, the machine has to look at its own last answer and decide. It needs flags — and that's next.