Fetch, Decode, Execute
The CPU runs one loop, forever, and it has only three steps. Step through it yourself and watch the instruction pointer walk down the program.
A CPU is, at heart, an extremely fast and extremely literal reader.
It keeps a finger on its place in the program. It reads the instruction under its finger. It works out what that instruction means. It does it. It moves its finger to the next one. Then it does the whole thing again, roughly a billion times a second, until you turn the computer off.
Those three steps have names:
┌──────────► FETCH read the instruction at the finger
│ │
│ ▼
│ DECODE work out what it means
│ │
│ ▼
└────────── EXECUTE do it, then move the fingerThat is the fetch-decode-execute cycle, and it really is the whole machine. Everything else in this course is detail about what individual instructions do inside the EXECUTE box.
In the fetch-decode-execute cycle, what happens during DECODE?
- AThe CPU works out which operation the fetched instruction represents and which values it needs
- BThe CPU reads the next instruction from memory
- CThe CPU performs the arithmetic and stores the result
- DThe CPU decrypts the instruction so it cannot be read from memory
The finger has a name. It is a special register called RIP, the instruction pointer, and it holds the address of the next instruction to run.
That one sentence explains more than it looks like it does:
- Running a program forwards is just RIP counting up.
- A jump is nothing more exotic than writing a new value into RIP.
- A function call saves the old RIP somewhere so it can be restored afterwards.
- A crash where the program "ran off into nowhere" is RIP holding an address with no valid instruction at it.
Every control-flow feature you have ever used (if, while, for, function calls, exceptions, generators) is ultimately somebody choosing a value for RIP.
What does the RIP register hold?
- AThe address of the next instruction the CPU will run
- BThe result of the last arithmetic operation
- CThe address of the program's data section
- DThe number of instructions executed so far
Time to watch it. Below is a five-instruction program. Two things to do:
1. Press Step once per instruction and watch the ▸ marker move down the left margin. That marker is RIP.
2. Notice that the panel on the right also shows rip, counting up in step with the marker.
If you lose track, Back rewinds one instruction and Reset puts everything back to the start. Nothing you do here can break anything.
Watch RIP walk
Step through all five instructions. The marker in the margin is the CPU's finger.
mov rax, 1
mov rbx, 2
add rax, rbx
add rax, rax
mov rcx, raxYou single-step that program. After exactly three steps, what does RAX hold?
mov rax, 1
mov rbx, 2
add rax, rbx
add rax, rax
mov rcx, rax- A3
- B1
- C2
- D6
One honest simplification, flagged now so it does not mislead you later.
Our simplified model: the CPU finishes one instruction completely, then starts the next. What a real CPU does: it works on a dozen or more instructions simultaneously in a pipeline, guesses which way branches will go before it knows (branch prediction), and may execute instructions out of order as long as the visible result matches the simple model.That sounds like it would break everything. It does not, because the hardware guarantees the results look exactly as if instructions ran one at a time, in order. So the simple model is not a lie you will have to unlearn: it is the contract the hardware promises to honour. It only leaks in two places, and both come much later than this course: multi-threaded code sharing data, and timing-based security attacks.
Real CPUs overlap and reorder instructions. Why is the one-at-a-time model still correct to reason with?
- AThe hardware guarantees the visible results match what one-at-a-time execution would produce
- BReordering only happens on server processors, not on laptops
- CThe operating system disables reordering for user programs
- DReordering is rare enough that it can safely be ignored
- A CPU repeats one loop forever: fetch the next instruction, decode what it means, execute it.
- RIP is the instruction pointer, holding the address of the next instruction. It is the CPU's finger on the page.
- Running forwards is RIP counting up. A jump is just writing a new value into RIP, which is where every if, loop and function call ultimately comes from.
- Our simplified model is one instruction at a time. A real CPU pipelines, predicts branches and reorders, but guarantees the visible result matches the simple model.
- In this course's simulator, RIP shows a line number rather than a byte address, purely so it is readable.
Next lesson: where the CPU keeps the values it is working with, and why it is not memory.