Don't Panic — ARM Architecture

Arm architecture is the agreement between software and a processing element: it says which instructions, registers, exceptions, and memory rules exist, while remaining conspicuously uninterested in how the chip earns its lunch. That division is useful. Software needs a dependable contract. Hardware designers need room for pipelines, caches, prediction, and other machinery that makes the same instruction complete at noticeably different speeds.

The first trap is a word that sounds more specific than it is. arm64 usually points toward AArch64, the 64-bit execution state. It does not identify a particular Cortex core, cache layout, or optional feature. A64, the instruction set used in that state, has 32-bit instructions. The name is not lying exactly; it is merely standing at an angle that encourages confusion.

The next useful map has three profiles. A-profile serves application systems, R-profile serves timing-sensitive real-time work, and M-profile serves small microcontrollers. Cortex is a processor brand, not a fourth profile or an architecture version. Before following a register name or exception rule, identify the profile, version, execution state, and instruction set. This sounds bureaucratic until a manual answers a perfectly good question about a different machine.

For A-profile work, the programmer's model is the visible furniture: registers, instructions, execution state, exception state, and memory rules. In AArch64, X0 and W0 are two widths of the same register storage. Writing W0 clears the upper half of X0. The procedure call standard then adds the social rules: how separately compiled functions pass arguments, return results, and avoid wrecking each other's registers.

Exceptions and memory are where the contract becomes less decorative. An exception transfers control to privileged software through an exception vector. Exception levels commonly map application code to EL0 and an operating-system kernel to EL1, but the labels are conventions. Memory mappings also carry permissions, execute controls, cacheability, shareability, and a memory type. A peripheral register is not ordinary storage wearing a funny hat; Device memory needs device access behavior.

The other surprise is that instruction order and memory observation order are separate problems. A processor can preserve the required instruction behavior while accesses become visible in another order. Dependencies, acquire and release operations, and barriers exist for the low-level boundary. Application code normally uses its language's atomic operations, which saves everyone from becoming an amateur memory-model archaeologist before breakfast.

Read the Course tab for the full map and Glossary when the names begin breeding. Use Slides for the relationships, Cheatsheet for the document-routing and diagnostic questions, and Reference for the official path from introductory guides to the architecture manual. Keep one rule nearby: architecture tells you what software may assume; processor and system documents tell you what this particular machine actually does.

Don't Panic — ARM Architecture

Relevant careers