Inside the instruction set

An instruction set architecture is a specification, not a chip. It defines everything a program, compiler or operating system can observe about the processor, and leaves everything else (pipeline depth, cache sizes, predictor design) to the implementation. Amdahl, Blaauw and Brooks drew this line when designing the IBM System/360, and it is why the same binary can run on a phone core and a server core that share an ISA.

Registers are the fastest storage in the machine, and the ISA fixes how many a program can name. More registers mean fewer spills to memory, but each one costs encoding bits in every instruction that names it, plus register-file area, read ports and save/restore time on a context switch.

Byte order is part of the data definition. Storing the 32-bit word 0x12345678 at address 0x100 lays out bytes differently:

Encoding decides how hard instructions are to fetch and decode. Fixed-length encodings (AArch64, RISC-V, MIPS: 4 bytes) let a wide core find instruction boundaries trivially and decode many instructions in parallel. Variable-length encodings (x86: 1 to 15 bytes) pack common operations into fewer bytes but force the decoder to find each instruction's length before it can start the next. A middle path adds a 16-bit compressed subset: Arm Thumb-2 and the RISC-V C extension.

RISC-V uses six 32-bit formats. Register specifiers always sit in the same bit positions, so the register file can be read before the decoder has finished working out what the instruction is. Immediates are split across fields so that the sign bit is always bit 31.

An addressing mode is the recipe for the effective address. Rich modes let one instruction do the work of several; simple modes keep the pipeline short and regular. Studies of VAX programs in the early 1980s found that a few modes (register, immediate, displacement) covered the large majority of uses, a key argument for RISC.

Instruction sets group operations into a handful of categories: data transfer (load, store, move), integer arithmetic and logic, control flow (branches, jumps, calls, returns), floating point, SIMD or vector, atomic memory operations, and system instructions (traps, fences, cache and TLB control).

Conditional branches come in two styles. Condition codes (x86 RFLAGS, Arm NZCV) are set as a side effect by arithmetic, and a later branch tests them. That saves an instruction but creates an implicit dependency on a single shared register that out-of-order hardware must rename. Compare-and-branch (RISC-V, MIPS) puts the comparison in the branch itself, so there is no hidden state, at the cost of encoding two register fields in every branch.

Atomics also split two ways. Load-reserved/store-conditional (RISC-V LR/SC, Arm LDXR/STXR) builds any read-modify-write from two simple instructions. Single atomic instructions (x86 lock cmpxchg, Arm LSE, RISC-V AMOs) perform the operation in one step and scale better under contention.

An exception is caused by the instruction itself (page fault, illegal instruction, system call); an interrupt comes from outside (timer, device). Modern ISAs require precise exceptions: when the handler runs, every earlier instruction has completed and no later one has changed visible state. Out-of-order cores pay for this with the reorder buffer.

The memory consistency model is the most subtle part of a multicore ISA. A weaker model gives hardware more freedom to reorder and buffer memory operations; a stronger model is easier to program. Binary translators such as Apple's Rosetta 2 must preserve x86 TSO behavior on weakly ordered Arm hardware, and Apple Silicon includes a hardware TSO mode for that reason.

Stack and accumulator code is compact because operands are implicit, which is why virtual ISAs like the JVM and WebAssembly use a stack: small downloads, easy verification. Load–store machines need more instructions, but every instruction is simple, registers are explicit, and the compiler can schedule freely. Since about 1980 nearly every new general-purpose ISA has been load–store.

CISC designs of the 1970s (VAX, x86, 68k) aimed to close the "semantic gap" with rich instructions and addressing modes, implemented with microcode. The RISC work at IBM (the 801), Berkeley and Stanford showed that compilers used a small subset of those instructions, and that a simple, pipelined load–store design with many registers ran faster. Since the Pentium Pro, x86 cores translate instructions into RISC-like micro-operations internally, so the old performance gap has largely closed.

VLIW (very long instruction word) moves scheduling from hardware to the compiler: each wide instruction bundles several independent operations that issue together. It succeeded in DSPs (TI C6000, Qualcomm Hexagon) where code is regular and power is tight, and struggled in general-purpose computing (Intel Itanium), where compilers cannot predict cache misses and branches well.

Packed SIMD (SSE, AVX, NEON) operates on fixed-width registers, so every widening (128 to 256 to 512 bits) adds a new set of instructions. Vector-length-agnostic ISAs (Arm SVE, RISC-V V) let one binary run on hardware with any vector width, reviving the approach of the Cray vector machines.

The ISA touches all three terms. Richer instructions lower the instruction count. Simple, regular instructions lower CPI because they pipeline well and decode in parallel. Decode complexity can lengthen the critical path and raise the cycle time, or force extra pipeline stages that make branch mispredictions more expensive.

Modern implementations blur these effects. x86 cores cache decoded micro-ops to skip the expensive decoder on hot loops, and both x86 and RISC cores fuse common instruction pairs (compare + branch, lui + addi) into one internal operation. Blem, Menon and Sankaralingam measured ARM and x86 cores and found that the ISA itself had no significant effect on performance or energy; microarchitecture and design targets explained the differences.

Where the ISA still clearly matters:

• Code density affects instruction-cache misses, fetch bandwidth, and flash cost in embedded parts.
• Decode width. Fixed-length instructions make 8-wide decode practical; variable-length decode costs area and power.
• Vector and matrix extensions give order-of-magnitude gains on the kernels they target.
• Memory model. Weaker ordering allows more aggressive store buffering; stronger ordering simplifies concurrent software.
• Ecosystem. Compilers, libraries and binary compatibility often outweigh any technical advantage.

A team building an audio processor finds that a dot-product kernel takes 60% of run time. On RV32IM the inner loop is 7 instructions:

Benefit. The kernel drops from 7 to 6 instructions. If CPI is unchanged, Amdahl's law gives 1 / (0.4 + 0.6 × 6/7) = 1.094, about a 9% speedup.

Cost. mac reads three registers (two sources plus the accumulator), so the register file needs a third read port, and a multiplier feeding an adder lengthens the critical path. If that raises the cycle time by 3%, the net speedup is 1.094 / 1.03 = 1.062. Every other program pays the 3% too, with no benefit.

Alternatives. Post-increment loads would remove both addi instructions, and a hardware loop would remove the branch, bringing the loop to 3 instructions. The PULP project's RI5CY core added exactly this set (MAC, post-increment loads, hardware loops) to RISC-V for near-threshold IoT signal processing.