Instruction Set
The instruction set is the contract between a program and the machine that runs it. Software is written against that contract, hardware is built to honour it, and neither side can change without the other. This chapter works through the contract from both directions: what an instruction is made of, how it says where its operands live, how the available instructions are classified, and what constraints push a designer towards one of two very different philosophies.
The first half is about encoding. An instruction is a bit pattern divided into fields — an operation code that names the operation, address fields that locate the operands, and sometimes control bits that qualify the operation. Two ways of allocating those bits dominate practice: a fixed-length operation code, which decodes quickly but wastes space, and an expanding operation code, which packs far more instructions into the same space at the cost of a more complicated decoder. Each arrangement is drawn as a field diagram so that the trade-off is visible rather than asserted.
The second half is about addressing. The same operation can fetch its operand from a literal inside the instruction, from a fixed address, from an address held in memory, from a register, or from a register-plus-offset combination, and each of these choices costs a different number of memory accesses. Immediate, direct, indirect, register, register-indirect, base, indexed, and relative addressing are introduced in that order, together with the formula for the effective address in each case, so the effect on execution cost is always explicit.
The closing section sets CISC against RISC. The comparison is not a verdict but a set of axes — instruction complexity, instruction length, addressing richness, control implementation, decode cost, code density, and pipeline behaviour — and the chapter ends by showing how the modern industry dissolved the argument: x86-64 keeps a CISC interface for compatibility while translating internally into RISC-like micro-operations, while ARM and RISC-V absorb selected CISC conveniences to improve code density. Understanding the axes is what lets you judge a new processor proposal on its merits rather than by its label.
Nothing here assumes prior study of a particular architecture, but the data representation chapter that precedes it is worth having read, since an instruction field is a fixed number of bits and the encodings make sense only in the light of how those bits are used.