Instruction set architecture

Lore & Background

The concept of an architecture distinct from the design of a specific machine was developed by Fred Brooks at IBM during the design phase of System/360. Prior to System/360, computer designers had been free to honor cost objectives by selecting technologies and fashioning functional and architectural refinements. The SPREAD compatibility objective postulated a single architecture for a series of five processors spanning a wide range of cost and performance, preventing engineering teams from adjusting architectural specifications to ease cost or performance difficulties.

An ISA can be extended by adding instructions or other capabilities, or adding support for larger addresses and data values. An implementation of the extended ISA will still be able to execute machine code for versions of the ISA without those extensions, while machine code using those extensions will only run on implementations that support them. Some virtual machines that support bytecode as their ISA, such as Smalltalk, the Java virtual machine, and Microsoft's Common Language Runtime, implement this by translating bytecode for commonly used code paths into native machine code, while executing less frequently used code paths by interpretation. Transmeta implemented the x86 instruction set atop very long instruction word (VLIW) processors in this fashion.

ISAs may be classified by architectural complexity. A complex instruction set computer (CISC) has many specialized instructions, some rarely used. A reduced instruction set computer (RISC) simplifies the processor by efficiently implementing only frequently used instructions, with less common operations implemented as subroutines. Other types include VLIW, LIW, and EPIC architectures, which exploit instruction-level parallelism by making the compiler responsible for instruction issue and scheduling. Architectures with even less complexity, such as MISC and OISC, are theoretically important but have not been commercialized.

Reader's Guide

The binary compatibility that ISAs provide makes them one of the most fundamental abstractions in computing. An ISA specifies the behavior implied by machine code running on an implementation in a fashion that does not depend on the characteristics of that implementation, enabling multiple implementations that differ in performance, physical size, and monetary cost to run the same machine code. This allows a lower-performance, lower-cost machine to be replaced with a higher-cost, higher-performance machine without replacing software. It also enables the evolution of microarchitectures, so that a newer, higher-performance implementation of an ISA can run software from previous generations.

If an operating system maintains a standard and compatible application binary interface (ABI) for a particular ISA, machine code will run on future implementations of that ISA and operating system. However, if an ISA supports running multiple operating systems, it does not guarantee that machine code for one operating system will run on another, unless the first operating system supports running machine code built for the other operating system. Processors with different microarchitectures can share a common instruction set; for example, the Intel Pentium and the AMD Athlon implement nearly identical versions of the x86 instruction set but have radically different internal designs. The ISA's role in enabling software portability across diverse hardware implementations has been central to the development of modern computing.

The ISA as a Bridge Between Software and Hardware

The ISA functions as the critical interface layer separating software from hardware. Because it defines the contract that both sides must honor, a single ISA can be realized through multiple distinct implementations that differ in speed, physical footprint, and price. This separation is what makes binary compatibility across generations of machines straightforward to achieve, and it underpins the concept of computer families. The practical consequence is significant: the cost of computing has been driven down, and the range of applications computers can serve has broadened. In essence, the ISA is one of the most consequential abstractions in modern computing precisely because it decouples the programmer's world from the engineer's world. A machine language programmer needs only to understand what the ISA specifies, while hardware designers are free to innovate in how they realize that specification.

The Comprehensive Scope of an ISA Specification

An ISA lays out everything a machine language programmer must know to write code for a given computer. The exact contents vary from one ISA to another, but in general the specification covers the supported data types, the state available to the program (such as main memory and registers) along with the semantics governing that state (including memory consistency rules and addressing modes), the full set of machine instructions that constitute the machine language, and the input/output model. This comprehensive scope means the ISA is not merely a list of operations; it is a complete abstract model of the machine. The programmer interacts with this model, never with the physical circuitry beneath it. The ISA thus serves as the definitive boundary: everything above it is software, everything below it is implementation detail that the programmer need not concern themselves with.

The Evolution of Data Representation and Word Width

Early computers in the first three quarters of the twentieth century employed a variety of number bases, including binary, decimal, and even ternary. Today, virtually all machines are binary. Integers have been encoded using sign-magnitude, ones' complement, two's complement, offset binary, and complement-based schemes, while floating-point formats have ranged from IBM hexadecimal to the now-dominant IEEE 754 standard. The notion of an n-bit architecture has shifted dramatically: word sizes of 12, 18, 24, 30, 36, 48, and 60 bits were common in the mid-twentieth century, giving way to 8, 16, and 32 bits, and now 16, 32, or 64 bits in the twenty-first century. Importantly, the nominal bit width is a simplification. Architectures like the Z80, MC68000, and IBM System/360 include instructions that operate on data sizes different from the processor's primary datapath, and the external bus width does not determine architectural width. For example, the PowerPC 604 features a 64-bit bus yet only 32-bit registers.

Instruction Structure: Opcodes, Modifiers, and Addressing Modes

The internal structure of an instruction varies considerably across architectures. Some designs use a single opcode per instruction, while others layer modifiers on top of a base opcode; the IBM System/370, for instance, uses byte 0 as the primary opcode but requires byte 1 to select the specific operation when byte 0 is a particular value. Other ISAs employ opcode prefixes that either alter the meaning of a subsequent opcode or expand the total number of available operations. Beyond the opcode, instructions must specify how their operands are located. Architectures typically offer a combination of addressing modes: direct (the instruction carries a complete address), immediate (the instruction carries the value itself), indexed (a register supplies an offset, sometimes scaled by operand length), indirect (the instruction points to a pointer word, potentially through multiple levels of indirection), and truncated (the instruction provides only low-order bits while a register supplies the rest). This rich vocabulary of operand specification gives programmers fine-grained control over how data is located and manipulated.

Gallery