Instruction Set Architecture as a Contract

An Instruction Set Architecture is the complete specification of the programmer-visible behavior of a computer: the set of instructions it executes, the registers and memory locations it exposes, the data types and sizes it supports, and the rules that determine what state changes result from each instruction. It says nothing about clock speed, pipeline depth, number of execution units, or transistor layout. Two processors with identical ISAs can have utterly different internals — one might execute instructions strictly in program order at 1 GHz, another might execute them out of order across eight pipelines at 4 GHz — yet both must produce bit-for-bit identical results on any program, differing only in how fast the answer arrives. This split has a name in systems design: the hardware/software interface. Below the line sits the microarchitecture — the actual implementation: the Fetch-Decode-Execute Cycle realized as concrete circuits, control logic, datapaths, caches, and pipelines. Above the line sits everything software — compilers, operating systems, application code — that only ever needs to know the contract, never the circuit. The ISA is the contract itself, and like any good contract it is judged by what it omits as much as by what it states. It must not leak implementation details that would tie software to one particular chip design, yet it must be precise enough that two independent hardware teams, given only the ISA document, could build interoperable chips. Formally, an ISA specification answers five questions. First, what is the programmer-visible state — the set of general-purpose registers, special registers (program counter, status/flags register, stack pointer), and the addressable memory space? Second, what are the instructions — the exact operations (add, load, branch, and so on) available to manipulate that state? Third, what are the instruction formats and encodings — how is each instruction represented as bits (foreshadowing a dedicated later treatment)? Fourth, what are the data types and sizes supported natively (8/16/32/64-bit integers, floating point, and so on)? Fifth, what is the memory model — how do reads and writes to memory behave, especially when multiple instructions or multiple processors interact with the same location. A specification silent on any of these leaves an ambiguity that different implementations could resolve differently, breaking the contract's whole purpose.

The ISA "works" not as an algorithm executed at runtime, but as a specification that constrains two independent processes: how a compiler translates programs, and how a processor's control logic implements execution. The cleanest way to see the mechanism is to trace a single high-level statement down through the contract to concrete bits, and to see the same contract honored by two different implementations. Consider the C statement `c = a + b;`, where `a`, `b`, `c` are memory variables. A compiler targeting a given ISA must emit a sequence of instructions drawn only from that ISA's defined instruction set, using only its defined registers, and relying only on guarantees the ISA makes about memory behavior. The compiler has no say in, and no visibility into, how the chip internally executes those instructions. ``` PSEUDOCODE: compiling "c = a + b" against an ISA contract given ISA-defined resources: registers R0..R31 # general-purpose register file instruction LOAD Rd, [addr] # Rd <- Mem[addr] instruction STORE Rs, [addr] # Mem[addr] <- Rs instruction ADD Rd, Rs1, Rs2 # Rd <- Rs1 + Rs2 compile("c = a + b"): emit LOAD R1, [a] # bring operand a into a register emit LOAD R2, [b] # bring operand b into a register emit ADD R3, R1, R2 # compute the sum in a register emit STORE R3, [c] # write result back to memory return instruction_stream ``` Every line in this emitted stream refers only to concepts the ISA promises: a fixed register file, a defined arithmetic instruction, a defined memory access instruction, and an implicit but crucial guarantee — that `LOAD` reads the most recently `STORE`d value at that address, in program order, from the point of view of this single instruction stream. That guarantee is part of the ISA's memory model and is exactly the kind of rule software silently depends on without ever thinking about it. Now consider what a processor's control logic must do to honor this contract, independent of the compiler: ``` PSEUDOCODE: honoring the ISA contract during execution (one possible microarchitectural realization) loop forever: instr = Memory[PC] # fetch: read next instruction op, args = decode(instr) # decode: interpret per ISA encoding rules switch op: case LOAD: Rd = args.dest addr = compute_address(args) Registers[Rd] = Memory[addr] # contract: Rd gets Mem[addr] case STORE: addr = compute_address(args) Memory[addr] = Registers[args.src] case ADD: Rd = args.dest Registers[Rd] = Registers[args.src1] + Registers[args.src2] case BRANCH: if condition_holds(args): PC = args.target continue # skip default PC increment PC = PC + instruction_size # contract: sequential execution

# unless a branch/jump says otherwise ``` This loop is one legitimate implementation of the Fetch-Decode-Execute Cycle discussed elsewhere, but it is not the only one honoring the same contract. A different implementation could fetch several instructions per cycle, reorder independent `LOAD`/`ADD` pairs for speed, or split `Memory[addr]` access across multiple cache levels — as long as the externally observable result matches what this simple sequential loop would produce. That final clause is the entire point: the ISA specifies observable behavior, not execution mechanism, so any implementation reproducing the same observable results is a legal implementation of the same contract. The figure below makes this boundary explicit as a layered diagram: software above the line, hardware below, with the ISA as the single narrow interface connecting them.

The ISA is not an algorithm, so it has no time or space complexity of its own; the meaningful complexity questions instead concern the cost of specifying and implementing it, and the correctness question is really a question of implementation conformance — does a given chip faithfully realize the contract?

Specification size and encoding cost. An ISA with $n$ distinct instructions, each needing to be uniquely identifiable, requires an opcode field of at least $\lceil \log_2 n \rceil$ bits purely by the pigeonhole principle: fewer bits cannot distinguish $n$ symbols. This is the seed of the RISC-vs-CISC tension (a smaller, regular instruction set needs fewer encoding bits and simpler decode logic, while a larger, richer one needs more) and is developed fully elsewhere; here it matters only as a reminder that even a "pure specification" concept like an ISA has hard combinatorial costs baked into it.

Conformance is the correctness property. A microarchitectural implementation $M$ is a correct implementation of ISA $I$ if and only if, for every program $P$ expressible in $I$ and every valid input, running $P$ on $M$ produces the same sequence of observable state changes (register values at completion, memory contents, output side effects) as the reference architectural semantics of $I$ prescribe — regardless of internal timing. Formally, if we let $\text{sem}_I(P)$ denote the abstract state trace the ISA specifies for program $P$, and $\text{exec}_M(P)$ denote what implementation $M$ actually produces, correctness requires:

where $\equiv$ compares only architecturally visible state, never internal microarchitectural state (pipeline stage contents, cache line placement, branch predictor tables) since the ISA makes no promises about those at all.

Why this enables sound reasoning. This equivalence is precisely what licenses two separate engineering teams to work without coordination. The compiler team can prove their translation correct against $\text{sem}_I$ alone — a fixed, stable target — without ever considering $M$. The chip team can prove their pipeline correct by showing $\text{exec}_M \equiv \text{sem}_I$ through techniques like pipeline hazard detection and forwarding logic, without knowing what programs will run. The whole edifice of hardware/software co-development rests on this equivalence being maintainable independently on both sides. If the contract were leaky — if, say, correct program behavior depended on exactly how many pipeline stages a chip had — this decoupling would collapse, and every compiler would need to be rewritten for every new chip generation.

Honest tradeoffs. The contract's strength is also its constraint. A stable ISA freezes decisions (register count, instruction semantics, memory ordering rules) that become expensive to change later; adding a new instruction or register means either extending the ISA (breaking strict backward compatibility guarantees, as x86 has done repeatedly via extensions like SSE and AVX) or working around the limitation in software, at a performance cost. Conversely, the freedom the contract grants hardware is bounded by whatever the architects thought to specify: an ISA that under-specifies memory ordering, as several real architectures historically did, forces every future chip either to over-constrain itself for safety or to expose subtle portability bugs that only manifest under aggressive reordering — a lesson that motivated much more careful memory-model specifications in modern ISAs.

Trace the same architectural instruction, `ADD R3, R1, R2` (with `R1 = 12`, `R2 = 30`), through two different implementations of one hypothetical ISA, to see the contract preserved while internals diverge sharply.

Setup. The ISA specifies: general-purpose registers `R0`–`R7`; instruction `ADD Rd, Rs1, Rs2` meaning `Rd ← Rs1 + Rs2`; and the architectural guarantee that after this instruction retires, `Rd` holds the arithmetic sum and no other architectural state changes.

Both implementations take a different number of cycles, use different internal resources (a single ALU versus two, in-order versus reordered scheduling), and yet the row "Architectural result" is identical — exactly what the ISA's contract requires and exactly all it requires. Implementation B might finish faster if the two dispatched instructions are truly independent, or it might stall for extra cycles resolving a hazard the ISA never mentions; either way, no program relying only on the ISA can observe which implementation it is running on from the register and memory contents alone. This is the whole payoff of the contract, made concrete: performance differs by design, correctness does not. A second, subtler trace shows why the memory model clause of the contract matters just as much as the instruction list. Suppose two ISA-defined instructions execute back to back: ``` STORE R1, [X] ; Mem[X] <- R1 LOAD R2, [X] ; R2 <- Mem[X] ``` The ISA's memory model must state, unambiguously, that within a single instruction stream, a `LOAD` from an address observes the value of the most recent prior `STORE` to that same address, in program order — a property sometimes called program-order consistency for a single stream. Without this explicit guarantee, an aggressive implementation would be technically free to execute the `LOAD` before the `STORE` completes (since they look independent to naive scheduling hardware), silently returning stale data and breaking every program that relies on sequential store-then-load semantics — which is essentially all of them. The guarantee costs the hardware design something (it must detect this address dependency and stall or forward the value), but paying that cost is precisely what the contract obligates it to do.

The idea of separating "what a machine computes" from "how it computes it" traces back to the earliest formal treatments of computation, but its concrete, industrial form — a written specification that multiple hardware implementations must obey — crystallized with the IBM System/360 project, where architects explicitly promised that a single instruction set would span an entire family of machines differing enormously in cost and speed.

Every modern computing platform depends on the ISA-as-contract idea to function at all. Intel and AMD chips of vastly different internal design — different pipeline depths, different cache hierarchies, different branch predictors — both execute x86-64 binaries identically at the architectural level, which is why a program compiled once can run on either vendor's silicon. ARM's licensing model exists because the ISA is separable from implementation: ARM Holdings defines the contract, while Apple, Qualcomm, and Samsung each build their own independent, competing microarchitectures that honor the same instruction set. Operating systems rely on the ISA's precisely defined privilege levels and trap/exception behavior to implement process isolation and system calls — the contract must specify not just normal instructions but exactly what happens when something goes wrong, since an OS kernel's correctness depends on that behavior being deterministic and specified, not left to chip-specific whim. The RISC-V project made the contract nature of the ISA explicit as a design philosophy: it publishes the instruction set as an open standard precisely so that no single company controls the boundary, letting many independent hardware implementations (in academia, startups, and large manufacturers alike) compete freely below a shared, stable line. Virtualization technology — the hypervisors underlying cloud computing — depends on being able to trap and emulate privileged ISA behavior precisely because that behavior is specified, not implementation-defined. And every compiler backend, from GCC to LLVM, is organized around exactly this boundary: a compiler's job ends the moment it has emitted a valid instruction stream conforming to the target ISA, after which the boundary anticipated by concepts like RISC versus CISC Design Philosophies and Instruction Formats and Encoding takes over to determine how those instructions are actually realized in silicon.

Ask the tutor: How does the ISA's memory model change when multiple processors share memory, and why does that make concurrent programming harder?