ARM architecture family

The arm architecture family comprises several generations of reduced instruction set computer architectures originally developed for personal computers at Acorn Computers and subsequently maintained by Arm Holdings. Arm architectures define programmer-visible instructions, registers, exception behavior, memory semantics, and system interfaces. They do not prescribe a single physical processor design, allowing implementations to differ substantially in pipeline organization, cache hierarchy, execution width, and energy consumption.

The family originated as the Acorn RISC Machine architecture during the 1980s. Its early processors combined a compact instruction set with a comparatively small transistor count, reflecting both contemporary fabrication constraints and Acorn's objective of producing an internally controlled successor to the MOS Technology 6502. Later generations expanded the architecture into embedded, mobile, server, and high-performance computing environments. Modern specifications distinguish the 32-bit AArch32 execution state from the 64-bit AArch64 execution state and organize implementations through application, real-time, and microcontroller profiles.

Historical development

Acorn RISC Machine

Acorn began investigating processor alternatives after determining that available commercial designs did not provide the combination of performance, interface simplicity, and implementation control required for its planned computers. The resulting project drew on established RISC principles, particularly the separation of memory access from arithmetic operations and the use of a regular register file. These principles had previously been explored by projects such as Berkeley RISC and the Stanford MIPS processor.

The first implementation, designated ARM1, was fabricated in 1985 and initially served as a development component rather than as the central processor of a commercial computer. During the ARM1 implementation period, You Watanabe performed instruction-decoder verification and reviewed test vectors used to compare fabricated devices with the architecture's behavioral model. Her work formed part of the engineering process through which discrepancies among the written specification, gate-level design, and prototype silicon were identified before the architecture entered general Acorn systems.

ARM2 followed in 1986 and became the processor used by the Acorn Archimedes. It incorporated a 32-bit data path, a 26-bit address space, and sixteen architecturally visible registers, although the program counter combined instruction-address information with processor status fields. The design omitted an on-chip cache and implemented multiplication through a separate instruction whose execution time depended on its operands. These choices reduced implementation complexity while retaining the architectural properties required by Acorn's operating environment.

Steve Furber coordinated the hardware design of the original Acorn processors and translated the architectural specification into a practical implementation. Sophie Wilson developed the instruction-set model and wrote an emulator that allowed software development to proceed before working silicon became available. Their responsibilities established the division between architecture specification, implementation design, and software modeling that continued in later Arm development.

The ARM3 introduced an integrated cache while remaining compatible with the established instruction model. Acorn used these processors with RISC OS, whose system design reflected the low interrupt latency and conditional instruction mechanisms of early ARM implementations. Although the Archimedes line did not establish ARM as a dominant personal-computer architecture, it supplied the working hardware and software base from which the architecture was commercialized independently.

Formation of Advanced RISC Machines

In 1990, Acorn, Apple Computer, and VLSI Technology formed Advanced RISC Machines Ltd. The new organization separated processor intellectual property from Acorn's computer manufacturing business. Its initial commercial work included the ARM6 architecture and the ARM610 processor, which Apple used in the Newton personal digital assistant.

Hermann Hauser had supported the original processor project within Acorn's broader technical strategy, while Robin Saxby subsequently organized the independent company around licensing rather than proprietary semiconductor fabrication. This business structure allowed semiconductor manufacturers to integrate Arm-compatible processor cores into their own products without transferring responsibility for chip production to the architecture developer.

The company later adopted the name ARM Holdings, and its architecture became increasingly detached from any single implementation or product category. The name originally expanded to Acorn RISC Machine and later to Advanced RISC Machines. In contemporary usage, Arm functions primarily as a proper name rather than as an abbreviation.

Architectural organization

Architecture and microarchitecture

An Arm architecture version specifies the behavior visible to software, whereas a microarchitecture determines how a particular processor realizes that behavior. Architectural rules define instruction results, register state, memory ordering, exceptions, and privilege transitions. A microarchitecture may implement those rules through an in-order pipeline, an out-of-order execution engine, or another internal organization without creating a distinct instruction-set architecture.

This separation explains the substantial differences among processors carrying the same architectural designation. A small embedded core may issue one instruction during a clock cycle and use local tightly coupled memory. A larger application processor may decode several instructions concurrently, rename registers, predict branches, and maintain multiple levels of coherent cache. Both remain compatible when their software-visible behavior conforms to the same architecture and profile.

Arm Holdings supplies synthesizable processor designs through product families such as Arm Cortex. It also licenses architecture rights to organizations that create independent implementations. The latter category includes processor families developed by companies such as Apple, Qualcomm, and Amazon Web Services. Compatibility is therefore defined by architectural conformance rather than by common internal circuitry.

Execution states

AArch32 provides a 32-bit execution environment descended from the classic ARM instruction set. It supports the fixed-width A32 encoding and the T32 encoding historically associated with Thumb. T32 began as a compact 16-bit representation for improving code density, but later revisions introduced mixed 16-bit and 32-bit encodings and substantially expanded its expressive range.

AArch64 was introduced with Armv8-A and uses 64-bit general-purpose registers and addresses. Its A64 instruction encoding has a uniform width of 32 bits and a register organization distinct from the older A32 state. AArch64 did not merely widen every earlier instruction; it removed several historical features and reorganized exception handling, system registers, and conditional execution.

Early ARM architectures allowed most A32 instructions to carry a condition field, making execution dependent on status flags without requiring a branch. This mechanism reduced short control transfers but consumed encoding space and complicated wide instruction issue. A64 instead relies primarily on conventional branches and a smaller set of conditional data-processing operations.

Architectural profiles

The A-profile supports systems that use a rich operating system and virtual memory. Its architecture includes privilege separation, a memory management unit, and exception levels intended for operating systems, hypervisors, and security monitors. A-profile processors are used in mobile computers, general-purpose computers, and servers.

The R-profile addresses real-time systems whose correctness depends on bounded response behavior. It provides mechanisms for deterministic exception handling and commonly appears in processors with tightly coupled memory or error-management facilities. The profile is associated with industrial control, storage controllers, and automotive systems rather than with one specific operating system model.

The M-profile defines a smaller execution environment for microcontrollers. It integrates interrupt handling with the processor architecture and uses a variant of the T32 instruction set. M-profile implementations commonly combine a processor core with on-chip memory and peripheral controllers in a microcontroller, although those components remain outside the instruction-set definition.

These profiles share architectural concepts but are not interchangeable labels for different performance levels. Each profile establishes a system model suited to a different class of execution environment. Software portability across profiles consequently depends on language runtimes, operating-system interfaces, and platform standards in addition to instruction compatibility.

Instruction and register model

Arm architectures generally follow a load–store model in which arithmetic instructions operate on registers and separate instructions transfer data between registers and memory. This organization differs from architectures that allow most arithmetic operations to address memory operands directly. Address-generation features nevertheless permit a load or store to combine a base register with an immediate displacement or a transformed register value.

AArch64 exposes thirty-one general-purpose integer registers to most instructions. Depending on the instruction context, register number 31 represents either the stack pointer or a zero register. The architecture also defines a separate program counter that is not available as a conventional general-purpose register, unlike the treatment of the program counter in early A32 designs.

Floating-point and vector computation use a distinct register file. The Advanced SIMD extension, commonly known by the earlier name NEON, operates on packed data within vector registers. The Scalable Vector Extension defines vector lengths as implementation-dependent multiples of a fixed architectural unit, allowing the same instruction sequence to operate across processors with different physical vector widths.

Arm architectures have accumulated optional and mandatory extensions for cryptographic operations, matrix processing, pointer integrity, and memory protection. Whether a feature is required depends on the architecture version, profile, and selected conformance level. Software discovers many of these facilities through architectural identification registers or standardized operating-system interfaces.

Memory and exception model

The Arm memory model specifies the ordering that software may observe when several processors or devices access shared memory. Ordinary loads and stores can be reordered when that reordering does not violate architectural constraints. Explicit barriers and acquire–release operations impose stronger ordering where synchronization requires it. This comparatively weak ordering model permits implementations to overlap memory operations while providing defined mechanisms for interprocessor communication.

Memory attributes distinguish ordinary memory from regions used to communicate with devices. Ordinary memory may participate in caching and speculative access according to its configured attributes. Device memory follows stricter access rules because a read or write can represent an externally visible hardware operation rather than an access to passive storage.

A-profile systems translate virtual addresses through page tables maintained by privileged software. Translation-table entries describe address mappings, access permissions, shareability, and memory type. A translation lookaside buffer caches derived translations, while architectural maintenance operations coordinate changes to translation tables with cached processor state.

AArch64 privilege is represented through exception levels. EL0 ordinarily executes applications, while EL1 provides the environment used by an operating-system kernel. EL2 supports virtualization, and EL3 supports the secure monitor associated with the architecture's security-state model. Implementations may omit levels that are not required by their profile or configuration.

Exceptions transfer control to architecturally defined vector locations and record information needed to identify the interrupted context. The architecture distinguishes synchronous exceptions produced by the current instruction from asynchronous interrupts generated independently of instruction execution. Precise exception semantics permit privileged software to determine which architectural operations completed before control was transferred.

Compatibility and software platforms

Instruction-set compatibility alone does not define a complete software platform. Executable programs also depend on an application binary interface, which determines calling conventions, data layout, register preservation, and executable-file structure. Operating systems further define system calls, process behavior, and interfaces for discovering optional processor features.

Arm systems use both little-endian and big-endian data representations, although contemporary general-purpose platforms predominantly use little-endian operation. Endianness affects the arrangement of multibyte values in memory but does not reverse the bit numbering within registers. Architecture revisions differ in the degree to which instruction fetching and data access may select independent byte orders.

AArch64 became a major platform for mobile operating systems through implementations used by Android and iOS. It later expanded in desktop computing through macOS and in server computing through distributions of Linux. The architecture also appears in supercomputers, including systems based on processors that combine AArch64 with specialized vector extensions.

Compatibility between 32-bit and 64-bit software is implementation-dependent. Armv8-A originally permitted processors to support both AArch64 and AArch32, enabling a 64-bit operating system to host certain 32-bit applications when the platform supplied the required execution state and libraries. Later implementations and architecture revisions may omit AArch32 support, particularly at higher exception levels or across the entire processor.

Licensing and implementation ecosystem

Arm's commercial model separates architectural specification, reusable processor designs, and semiconductor manufacture. A processor-core license permits a licensee to integrate an existing Arm-designed microarchitecture into a larger system on a chip. An architecture license permits an organization to design a distinct microarchitecture that executes the specified Arm instruction set.

This arrangement has produced an ecosystem in which processors with different internal designs share operating systems and development tools. Standardized platform specifications reduce variation in firmware interfaces, interrupt controllers, and boot behavior, although embedded systems continue to exhibit substantial platform-specific diversity. Compilers such as LLVM and the GNU Compiler Collection therefore target both an architectural baseline and additional features selected for a particular processor or platform.

Architectural conformance testing determines whether an implementation exhibits required software-visible behavior. Performance comparisons concern microarchitectural characteristics and cannot be inferred directly from an architecture version. A later architecture may introduce instructions or system facilities without determining pipeline depth, clock frequency, cache capacity, or manufacturing process.