Instruction sets: the contract beneath a program

For a small integer program, architectural state includes the program counter, integer registers, and relevant memory. An instruction reads part of that state and defines an allowed change. RV32I supplies 32 integer registers of 32 bits, with x0 fixed to zero. An ADD writes the low 32 bits of a sum to its destination; writing x0 discards the result. These rules are useful even before you know how many execution units a processor contains. They let you trace a program by hand.

Think of execution as repeated transitions rather than informal verbs such as add and jump. Specify operand width, destination, memory effects, and next instruction address. For an ordinary RV32I instruction without a control transfer, the next address advances by four bytes. This example deliberately excludes compressed instructions and traps. Extensions change the available instruction encodings and operations, so a binary built for an unsupported extension is not made compatible by using the same operating system name.

An ISA generally does not promise that one instruction occupies one cycle. Fetch, decoding, translation, operand readiness, execution resources, and memory access can all affect progress. A processor may split an architectural instruction into internal operations or overlap independent instructions. Another processor may implement the same visible contract more simply. Correct code relies on the documented results, exceptions, and memory rules rather than a drawing of one pipeline. Performance code also measures the particular implementation it intends to improve.

The contract has several layers. An ISA says what a call-related instruction does to registers or control flow. An application binary interface, or ABI, says which arguments use which registers and which registers a function must preserve. A language adds its own rules: an operation forbidden by the language can be optimized in ways that surprise someone reasoning only from hardware arithmetic. Inspect all relevant layers when an optimized program behaves unexpectedly, and resist treating the disassembly as the entire language specification.

A trace records the visible state after each instruction. Begin with known register contents, mark each source read, and update only the specified destinations. If an instruction overwrites a register, later instructions see the new value. If the destination is x0, later reads still return zero. A trace can expose a wrong register assumption without requiring performance tools. For memory operations, also record byte addresses and widths rather than drawing memory as an untyped list of numbers.

The probability lab models a different, deliberately narrower contract: exact binomial probabilities from a success probability and an integer trial count. Predict the mean from those inputs, then change one control and explain which outputs must change. This is a useful exercise in identifying a model boundary. It does not decode instructions, simulate a CPU, or measure branch behavior. Carry the same discipline back to machine code: read the model definition before deciding what an observation proves.