the fetch-decode-execute cycle
Imagine following a recipe: read the next step, understand what it asks, do it, then move your finger to the step below and repeat. A processor lives its entire life doing exactly this, billions of times a second, with no boredom and no skipping ahead unless told. This relentless loop — fetch, decode, execute, repeat — is the heartbeat of every processor, the thing it does over and over from the moment it powers on.
The cycle has clear steps. Fetch: read the next instruction from memory at the address held in the program counter, then advance the program counter. Decode: the control unit works out what the instruction means and which parts of the datapath it needs. Execute: the datapath does it — add, load from memory, store, or change the program counter to jump elsewhere. Then the loop begins again with the next instruction. Most instructions simply advance to the one after; branches and jumps make the cycle pick up from a different address instead.
This single loop is how a stored program comes alive: a list of instructions in memory is walked through, one beat at a time. It is also where almost every performance idea later in this domain plugs in — pipelining overlaps the steps of many instructions, out-of-order execution reorders the work while preserving the appearance of this orderly march, and branch prediction guesses the next address before fetch even finishes. Understand this loop and you have the spine the rest of the subject hangs on.
Fetch instruction add at address 100, advance the program counter to 104, decode it as an addition, execute by adding two registers, write the result, then fetch the instruction at 104 — and on it goes.
Fetch, decode, execute, repeat — the processor's unending heartbeat.
The clean three steps are a teaching model. Real chips overlap and reorder them heavily for speed, but they always preserve the illusion that instructions ran one after another in program order.