Instruction Set Architecture
The contract between software and hardware — and the distinction that most performance arguments get wrong: the same ISA is implemented by wildly different microarchitectures.
An instruction set architecture is the specification a compiler targets and a processor promises to honour: which instructions exist, which registers they name, how memory behaves, and how addresses are formed. Everything about how that promise is kept is deliberately outside it.
The instruction set is a specification; the microarchitecture is one machine that implements it. Confusing the two produces most of the bad arguments about processor performance, because it attributes to a published contract things that are properties of a particular chip.
Three instruction sets dominate current computing, and their differences are largely differences of origin and constraint rather than of achievable performance. Knowing what each optimised for explains their shape better than any claim about which is better.
The distinction described a genuine design disagreement about where complexity should live, and it mattered. Then implementations converged: complex instruction sets began decoding into simple internal operations, and reduced ones grew complex instructions. The labels survived the situation that gave them meaning.
Assembly is the readable form of what the machine will actually execute. Most engineers will never write it, and being able to read it is the single most direct way to check what the compiler did rather than guessing.
Instructions do not just name registers — they name ways of computing an address from registers, constants and a scale factor. The reason `arr[i]` costs one instruction rather than three is that the hardware performs exactly the arithmetic that array indexing requires.