Fetch → decode → execute, repeated endlessly as long as there is power — the processor reads the next instruction, works out what it means, and carries it out.

* A processor endlessly repeats fetch, decode and execute for each instruction, as long as it has power. *

At its heart a CPU is a simple loop. It maintains a program counter (the address of the next instruction), and on each turn it:

1. Fetches the next instruction — which raises the questions "what is the next instruction?" and "fetch it from where?"
2. Decodes it — works out the instruction format, which operation it is, what operands it takes, and where those operands come from and go to.
3. Executes it — actually performs the operation, then advances the program counter and loops.

Everything else in this topic hangs off this cycle. The ISA is the agreement that answers the decode questions (what instructions exist, what operands mean); the registers and memory are where operands live; the condition codes record results of execution; and control instructions (jumps, calls) change which instruction gets fetched next. Keeping this fetch-decode-execute loop in mind turns a pile of assembly facts into one coherent picture.

Go deeper:

• Instruction cycle (Wikipedia) — the fetch-decode-execute loop with a state diagram of each step.

The ISA is the visible interface between hardware and software — the "contract" defining everything a programmer needs to know to reason about the machine, while hiding how it is built.

* The ISA is the contract that splits the stack: how you program the machine above, what gets built in hardware below. *

A processor is enormously complex inside, but software shouldn't have to care about transistors and pipelines. The ISA draws a clean line: above it, compilers and programmers see a stable set of instructions, registers, and rules; below it, hardware designers are free to implement those however they like. As Amdahl, Blaauw and Brooks put it in 1964, the ISA is "the conceptual structure and functional behavior as seen by the programmer, as distinct from the data flow, logical design, and physical implementation."

What the ISA specifies:

• The instructions available (what operations exist)
• Data types and their sizes
• The registers (how many, how wide, their roles)
• How memory is addressed (byte ordering, addressing modes)
• The execution model (interrupts, exceptions, privilege)

Why it matters: because the contract is stable, the same binary runs on a simple in-order chip and a complex out-of-order superscalar one. The ISA "tells us what the processor will do, but not how it does it."

Analogy: an ISA is like a restaurant menu — you order dishes (instructions) without needing to know how the kitchen (the microarchitecture) prepares them.

Go deeper:

• Instruction set architecture (Wikipedia) — the canonical reference on the ISA as the hardware/software contract.