Instruction set architecture

An ISA defines the contract between software and a processor. It describes instruction encodings, operations such as arithmetic and branches, registers, addressing modes, supported data types, memory access rules, and the effects of exceptions and interrupts.¹ This contract allows many different processor designs to run the same compiled programs.

The ISA is distinct from microarchitecture, which is the internal organization used to implement it. Two processors can share an ISA while differing substantially in pipeline depth, cache hierarchy, execution width, power use, and performance. An ISA also differs from an application binary interface (ABI): the ISA defines machine operations, whereas an ABI adds conventions for function calls, binary formats, register usage, and operating-system interaction.

• Instruction set: the operations a processor can execute.
• State model: registers, program counter, flags, and memory-visible state.
• Execution rules: privilege, ordering, faults, interrupts, and atomicity.

ISA families balance compatibility, implementation complexity, code density, and performance. Complex instruction set designs such as x86-64 retain a large historical instruction vocabulary, while reduced instruction set designs generally use simpler, more regular instructions and rely on compilers for much of the work. The distinction is useful but not absolute: modern processors often translate architectural instructions into internal micro-operations.

Long-lived ISAs evolve through extensions rather than wholesale replacement. ARM supports several architectural profiles, including the 64-bit AArch64 state, while RISC-V defines a base integer ISA plus modular standard extensions for floating point, multiplication, atomics, vectors, and compressed instructions.³⁴ Compatibility rules determine whether new processors can run older binaries and whether operating systems must recognize new features.

Historical examples include IBM System/360, whose compatible family helped establish the commercial importance of an enduring ISA, and later architectures shaped by personal computers, mobile devices, and embedded systems.¹

An ISA provides the mechanisms an operating system needs to isolate programs and control hardware. Privilege levels, page-table operations, traps, interrupts, atomic read-modify-write instructions, and memory-ordering rules support kernels, processes, synchronization, and device drivers.² User programs normally access these facilities indirectly through system calls and libraries.

Compilers translate source languages into ISA instructions, selecting registers, branches, calling conventions, and instruction extensions. Assemblers expose the same operations in symbolic form, while debuggers and disassemblers interpret machine-code encodings. The ISA therefore affects compiler optimization, operating-system portability, binary compatibility, and the design of programming tools.

Memory semantics are especially consequential. An ISA may define strongly ordered behavior, permit certain reorderings, or provide explicit fences and acquire-release operations. These choices affect multicore synchronization and can make apparently similar programs behave differently across architectures. SIMD and vector facilities likewise expose parallel data operations, but their width, register model, and portability vary among ISAs.

Less visible ISA details often determine whether software is portable, secure, or easy to virtualize. An architecture may specify endianness, alignment requirements, illegal-instruction behavior, canonical address forms, floating-point exception modes, and whether unaligned memory accesses are supported. Such rules can matter as much as headline instruction counts.

Instruction encodings also create practical trade-offs. RISC-V compressed instructions reduce program size by using shorter encodings, while some architectures provide fixed-width instructions to simplify decoding; both approaches influence code density and hardware design.⁴ Optional extensions complicate compatibility because a binary may require features absent from a nominally related processor.

Virtualization depends on architectural support for safely presenting a guest operating system with a controlled view of privileged state. Security features can likewise become part of an ISA, including protected execution modes, memory permissions, pointer or branch protections, and instructions for cryptographic operations. Processor manuals, rather than marketing names, define the exact guarantees: Intel documents the programmer-visible behavior of its 64-bit architecture in the Software Developer’s Manuals, while Arm and RISC-V publish architectural specifications and extension requirements.²³⁴

ABI

Application binary interface: conventions governing binaries, calling conventions, data layout, and interaction with an operating system.

Microarchitecture

The internal processor implementation used to realize an ISA, including pipelines, caches, execution units, and prediction mechanisms.

Privilege level

An ISA-defined execution mode that controls access to sensitive instructions and machine state.

Memory model

Rules describing the ordering, visibility, atomicity, and effects of memory operations across processors and threads.

Instruction encoding

The binary representation of an instruction, including its operation code, operands, registers, and immediate values.