If you’re new to the Arm ecosystem, consider this a quick primer on terms you likely have seen before but might have questions about.

The Arm architecture is a family of Reduced Instruction Set Architectures (RISC) with simple addressing modes. Data processing is done on register operands otherwise relying on loads and stores to move data into and out of registers.

Arm Limited, the British company, stewards the Arm architecture.

ARM is a legacy acronym for Acorn RISC Machine, then Advanced RISC Machines. As we’ll see, with new advancements in the architecture, previous terms for things sometimes get renamed.

The Arm Architectural Reference Manual for A-profile architecture, affectionately referred to as the Arm ARM, is the programming manual for the architecture. If you’re doing anything with Arm assembly, you probably have this reference nearby.

Armv9 is the latest (as of this writing) in the family of architectures, featuring additions such as newer scalable SIMD vector (SVE2) and matrix (SME/SME2) operations and tracing functionality.

Armv9.4-A is the latest batch of extensions to Armv9. These extensions are documented in the Arm ARM. Some extensions are optional when introduced and many become mandatory in future revisions if they weren’t already when introduced.

The A in Armv9-A denotes the “Application Profile.” These support virtual memory via memory management units, and are what you’re likely to find on any Arm systems such as a phone, laptop, or server. There’s also the “R” profile for applications with real time system requirements, and “M” profiles which you’re more likely to find in microcontrollers which lack MMUs. The three architectural profiles are A, R, and M.

AArch64 is an execution state and was one of the larger additions with the introduction of ARMv8, which added support for 64b registers (31 general purpose registers, dedicated 64b stack pointer, 64b program counter that cannot be written to other than by branches or exceptions, and a zero-value pseudo-register) and addressing. At the same time, the AArch32 execution state was coined to refer to the legacy 32b functionality that folks were familiar with from ARMv7 (15 32b GPRs, no dedicated SP, PC is writable).

Curiously, the Arm ARM doesn’t mention the term ARM64; that seems to be a term preferred by Apple, Microsoft, and Linus Torvalds (that thread will always make me laugh, the maintainers of the port ultimately decided to use arm64 in the tree. The name ultimately makes sense; the arm64 Linux kernel port can execute userspace code in AArch64 or AArch32 execution states, though the kernel itself is AArch64-only).

If you want to learn about the calling convention (arguments are passed in which registers) used on these Arm systems, you might read the Procedure Call Standard for the Arm Architecture (aka AAPCS), which is published along with other documentation related to the ABI here. This made the previous APCS and TPCS standards obsolete. Apple platforms diverge from Arm’s ABI in specific ways. Microsoft also has docs (starting with a nice definition list like this post) on their ABI for Windows.

A64 is the instruction set introduced with AArch64. In fact, it is the only instruction set supported by AArch64. While registers in the AArch64 execution state are 64b, the instructions themselves are still only 32b (fixed width). A32 now refers to the older ISA, which was also 32b fixed width while T32 refers to the mixed 32b and 16b Thumb2 instructions. You may be familiar with those ISAs if you’ve worked with ARMv7 or older devices. A64 is a clean break from A32 and is a familiar but different ISA. For instance, much fewer instructions support predication in A64 than A32.

Not to be confused with A64, you might hear someone refer to a core as “being an A78,” or more formally Cortex-A78. Not only does Arm design the Arm architecture, but they also design implementations of the architecture which we call micro architectures. Regardless of the number that follows, if you see the terms Cortex or Neoverse, those are Arm-designed microarchitectures of the Arm architecture. Cortex-A78 for instance implements up to ARMv8.3 extensions. Wikipedia has a template that is a quick reference to the most recent Arm microarchitectures. Before we can talk more about microarchitectures in the Arm realm, we need to detour to topologies.

DynamIQ (and big.LITTLE before that) build upon the idea of using heterogeneous (different) cores rather than homogeneous (similar) cores for multi-core systems. I’m not sure this could still be considered symmetric multiprocessing. The advantage of this design is the flexibility to be good at different things at different times. We want large power hungry out of order processors to improve performance when we need it, but we might prefer slower in-order cores to help save power consumption (which would improve battery life). It’s interesting to see Intel doing something vaguely similar with the introduction of performance and efficiency cores in their Alder Lake microarchitecture.

By digging through the Technical Reference Manuals published by Arm for various microarchitectures, we can see an interesting evolution of support for various execution states with regards to various exception levels over time.

• A55: “Both the AArch32 and AArch64 execution states at all Exception levels (EL0 to EL3).”
• X1: “AArch32 Execution state at Exception level EL0 only. AArch64 Execution state at all Exception levels (EL0 to EL3)”
• X3: “AArch64 Execution state at all Exception levels, EL0 to EL3.” [i.e. no AArch32 support]

If an SoC were to be composed of heterogeneous cores with varying levels of AArch32 support, that would place interesting constraints on the operating system’s process scheduler; you can’t run an AArch32 program on a core that doesn’t support it!

Below are some more legacy terms. They might still be relevant, depending on how old some systems you still support are.

ARM9 (not to be confused with Armv9, the version of the architecture) is a family of cores, some implementing ARMv4t, some ARMv5.

StrongARM was a series of ARMv4 CPUs built by Digital Equipment Corporation; Intel acquired this IP as part of a settlement of a lawsuit, and eventually designed their own ARMv5 microarchitecture called XScale. Eventually Intel sold the PXA SoC family which was using XScale to Marvell. One wonders what the world may have looked like had Intel stuck with XScale in addition to or instead of Atom.

ARMv4t introduced a compressed instruction set called Thumb. Instructions were 16b fixed width (that said, there were some oddities like BL and BLX that were actually encoded as a pair of 16b instructions each; implementations had to take care that exception returns worked correctly if an exception occurred in the middle of the pair; it was implementation defined if that could even occur).

ARMv6t2 introduced Thumb2 which added more instructions including some 32b wide instructions to support wider immediates, new instruction suffixes to differentiate between narrow vs wide encodings, and a Unified Assembly Language (UAL) that made it easier to write assembler that was valid in Arm or Thumb mode. This made Thumb no longer fixed width though. The introduction of execution states with ARMv8 renamed Thumb to T32; there was no such T32 term when these instructions were introduced!

You may come across the term aarch64be being used in the context of toolchains, which is referring to big-endian. Arm has supported bi-endianness since ARMv4, though most platforms these days use Arm in little-endian endian configuration. Big-endian is more common in networking appliances since network byte order is BE. -mlittle-endian and -mbig-endian are the compiler flags one might use to control codegen. ARMv4 and v5 supported a BE-32 bus byte ordering. Code linked with --be32 produced big-endian code and data. ARMv6 added a new bus byte ordering called BE-8. --be8 produced little-endian code and big-endian data (the compiler would emit big-endian code for relocatable files when built with -big-endian, then the linker would convert these to little endian when --be8 was used. This allowed compilers to not worry about byte-reversing code regardless of what bus byte ordering was to be used at the expense of linker complexity). ARMv6 had both BE-32 and BE-8 bus byte orderings (the older BE-32 became optional), though ARMv7 removed support for BE-32. This post shows why BE-8 replaced BE-32; it was simpler to support systems of both endiannesses if we used little endian instructions and had the memory bus reorder the bytes on access. ELF uses the file format identifiers elf64-littleaarch64, elf64-bigaarch64, elf32-littlearm, and elf32-bigarm; though those identifiers don’t appear in ELF for the Arm {64-bit} Architecture.

That’s a quick glossary over common terms related to the Arm ecosystem. Hopefully in a follow up post we can review terms like VFP, Neon, OABI, and EABI, but these are enough for now.

Many thanks to my friends Peter Smith, Kristof Beyls, and Mark Brown of Arm, Arnd Bergmann of Linaro, and Ard Biesheuvel of Google, for proofreading drafts of this post and supplying insightful feedback. Coincidentally, while I was taking my time editing this post, my friend and colleague Fangrui Song beat me to the punch which another great blog post touching on very similar topics; you should check out his blog if you like this kind of content!