ARM Architecture

The Arm architecture is a functional contract between software and a processing element. It defines the behavior that software can depend on. That contract covers instructions, registers, exceptions, memory behavior, and debug facilities.

The contract is not a processor design. Two processors can implement the same Arm architecture while using different pipelines, cache sizes, and execution strategies. Their conforming software sees the same architectural behavior, but their performance and power use can differ.

This distinction gives you the first useful mental model:

software
   │ depends on
   ▼
Arm architecture ── implemented by ──> processor microarchitecture
   │                                      │
   │ common contract                      │ concrete design
   ▼                                      ▼
instructions, registers,             pipelines, caches,
exceptions, memory rules             timing, prediction

Use the architecture when you need to know what software may assume. Use a processor technical reference manual when you need implementation details. Use the system-on-chip documentation when you need the memory map, peripherals, or board-specific behavior.

Start with the three profiles

Arm divides its processor architecture into three profiles. Each profile targets a different class of system.

Profile	Primary design target	Typical software environment
A-profile	Application systems and high performance	Complex operating systems, applications, and virtualization
R-profile	Real-time systems	Timing-sensitive embedded control and safety-oriented workloads
M-profile	Microcontrollers	Small, power-constrained embedded systems

The profiles share architectural ideas, but they are not interchangeable labels. An A-profile operating-system kernel expects facilities that differ from an M-profile firmware environment. Identify the profile before reading register names, exception rules, or memory-management details.

Do not confuse a profile with a product family. Cortex is a brand for Arm processor implementations. Other vendors can also implement the Arm architecture. A processor name tells you which implementation you have. An architecture name tells you which contract it implements.

Decode architecture names

An architecture name combines a version and a profile. Armv8-A means version 8 of A-profile. Later revisions and extensions add features while preserving defined compatibility rules.

Three nearby terms answer different questions:

Term	Question it answers
Armv8-A or Armv9-A	Which architecture version and profile?
AArch64 or AArch32	Which execution state?
A64, A32, or T32	Which instruction set is executing?

In Armv8-A, AArch64 is the 64-bit execution state and uses A64. AArch32 is the 32-bit execution state and can use A32 or T32. A64 instructions are 32 bits wide; the number in A64 names the execution state, not the instruction width.

These distinctions prevent common mistakes. arm64 in a tool or operating system usually points toward the AArch64 software target. It does not identify a specific Cortex core, cache layout, or optional architectural feature.

The programmer's model

The programmer's model is the software-visible part of the architecture. It includes the register set, instruction behavior, execution state, exception state, and memory rules.

In AArch64, most integer work uses 31 general-purpose registers. You can view each register as a 64-bit X register or its low 32 bits as a W register. For example, X0 and W0 are two views of the same register storage. Writing W0 clears the upper 32 bits of X0.

X0: 63                                      32 31                0
    ┌────────────────────────────────────────┬───────────────────┐
    │ upper 32 bits                          │ W0                │
    └────────────────────────────────────────┴───────────────────┘

A64 also has separate floating-point and vector register views, system registers, a stack pointer, and a program counter. Register names carry meaning. They can select operand width, identify privileged control state, or expose a specific architectural feature.

Most application code reaches this model through a compiler and an application binary interface. The instruction set defines what operations exist. The procedure call standard defines how separately compiled functions exchange arguments, return results, use registers, and maintain the stack.

Instructions describe behavior, not scheduling

The A64 instruction set includes data processing, loads and stores, branches, system operations, and floating-point or vector operations. The architecture defines each instruction's encoding, operands, operation, restrictions, and possible exceptions.

Arm specifies instruction behavior through a simple sequential execution model. A processing element must behave as if it processes instructions in program order. A concrete processor may pipeline, speculate, or execute work out of order internally. Those choices are microarchitecture, and they must preserve the required architectural result.

This model does not mean every memory access becomes visible in program order. Instruction execution and memory ordering are related but separate architectural concerns.

Exceptions organize privilege and control transfer

An exception transfers control to privileged software because of an event. The event may be synchronous, such as a fault caused by an instruction, or asynchronous, such as an interrupt.

AArch64 A-profile uses Exception levels from EL0 through EL3. A common software mapping is:

EL3  secure monitor or platform firmware
EL2  hypervisor
EL1  operating-system kernel
EL0  application

The mapping is conventional, not the definition of the levels. The architecture defines privilege and control behavior. Software assigns roles within those rules. EL0 and EL1 are required in Armv8-A implementations; EL2 and EL3 are optional architectural levels.

When an exception is taken, the processing element saves architectural return state and transfers control through an exception vector. Software must preserve any additional state that its calling and exception conventions require. An exception return restores the saved execution context.

System registers are normally named for the lowest Exception level that can access them. The suffix in a name such as SCTLR_EL1 therefore tells you part of its access boundary.

Memory has type, attributes, translation, and ordering

The Arm memory model defines how software describes address regions and how memory accesses may be observed. In Armv8-A, the two high-level memory types are Normal memory and Device memory.

Normal memory holds code and data. It can use cacheability and shareability attributes.
Device memory represents peripherals and other locations that need stricter access behavior.

Treating a device register like ordinary cacheable memory can break hardware interaction. Treating ordinary memory like a device can disable useful behavior and can impose unwanted restrictions.

Translation tables map virtual addresses and attach access attributes. Those attributes include permissions, execute controls, memory type, cacheability, and shareability. The Memory Management Unit reads the tables during address translation.

Virtualization can add a second translation stage:

virtual address
   │ Stage 1, controlled by an operating system
   ▼
intermediate physical address
   │ Stage 2, controlled by a hypervisor
   ▼
physical address

Memory accesses can become visible in an order different from source or instruction order. Dependencies, acquire and release operations, and barriers establish ordering where software needs it. Use a language memory model and its atomic operations for portable concurrent code. Drop to architectural ordering primitives only when you own the low-level boundary.

Architecture, processor, and system are separate layers

You often need several documents to explain one machine:

Layer	Defines	Typical document
Architecture	Software-visible behavior	Arm Architecture Reference Manual
Processor microarchitecture	Core-specific features and implementation choices	Processor Technical Reference Manual
System architecture	Shared components and interfaces	GIC, SMMU, AMBA, or platform specification
System-on-chip	Integrated memory map and peripherals	Vendor datasheet or reference manual
Board	Connectors, clocks, firmware, and wiring	Board manual and schematics

The Arm architecture does not define the whole computer. Interrupt controllers, interconnects, device translation, firmware interfaces, and board devices have their own specifications. A correct low-level diagnosis starts by asking which layer owns the observed behavior.

Optional features require discovery

Architecture versions define mandatory and optional features. A processor can implement the required base while omitting an optional extension. Software must not infer every feature from a broad label such as AArch64.

At a low level, architectural identification registers report implemented features. Operating systems commonly expose a safer platform interface to applications. Toolchains also need an explicit architecture and feature target so they do not emit instructions unavailable on the deployment processor.

The rule is simple: compile for the minimum environment you promise, discover optional capabilities through the platform, and select optimized code only when support is present.

Where Arm architecture knowledge helps

This knowledge is useful when you:

Read compiler output or debug a crash at instruction level.
Port an operating system, hypervisor, runtime, or firmware component.
Choose a build target and reason about binary compatibility.
Configure page tables, memory attributes, exceptions, or device access.
Investigate concurrency failures that depend on memory ordering.
Separate a portable software problem from a processor-specific performance problem.

It is not enough for cycle-level optimization, board bring-up, or peripheral programming by itself. Those tasks require the processor, system-on-chip, and board documentation as well.

A practical learning path

Learn the architecture-versus-microarchitecture boundary.
Identify A-profile, R-profile, and M-profile use cases.
Decode architecture versions, execution states, and instruction-set names.
Read the AArch64 register and instruction model.
Follow one synchronous exception from EL0 to EL1 and back.
Map a virtual page and explain each memory attribute.
Study acquire, release, and barrier behavior through small concurrency cases.
Learn the procedure call standard before mixing assembly with compiled code.
Use the Arm Architecture Reference Manual for exact rules.
Add the target processor and system documentation for implementation work.