ARM64 is the common name for the 64-bit execution state of the Arm architecture, formally called AArch64 and introduced with the Armv8-A specification. In processors, it defines the instructions, registers and memory model that a CPU must implement to run 64-bit Arm software, independent of how any particular chip is built internally.
Arm Holdings licenses the architecture rather than manufacturing chips. Companies either license ready-made CPU core designs such as the Cortex and Neoverse families or obtain an architecture license to design their own compatible cores. As a result, ARM64 runs on hardware ranging from smartphones and tablets to laptops, game consoles and cloud servers.
How the ARM64 architecture is defined
ARM64 is a load-store RISC architecture: arithmetic instructions operate only on registers, and separate load and store instructions move data between registers and memory. Every instruction is a fixed 32 bits long, which makes decoding simpler and allows wide front ends that decode many instructions per clock cycle.
The programmer-visible state is generous. AArch64 provides 31 general-purpose 64-bit registers (X0 to X30), a dedicated stack pointer and zero register, and 32 vector registers of 128 bits for floating-point and SIMD work. The architecture uses a weakly ordered memory model, so software relies on explicit barriers and acquire-release instructions when threads share data.
The table below lists the main architectural features and why they matter.
| Feature | Specification | Practical effect |
|---|---|---|
| Instruction length | Fixed 32 bits | Simple, parallel decoding |
| General-purpose registers | 31 registers of 64 bits | Fewer memory accesses for temporaries |
| SIMD registers | 32 registers of 128 bits (NEON) | Media, cryptography and ML kernels |
| Exception levels | EL0 to EL3 | Clean separation of apps, OS, hypervisor and firmware |
| Memory model | Weakly ordered | Higher performance, explicit synchronization |
| Virtual addressing | 48-bit, optionally 52-bit | Large address spaces for servers |
ARM64 versions and extensions
The architecture evolves through numbered versions and optional extensions, so two ARM64 processors can support different instruction sets. Software compiled for a newer baseline may not run on an older chip, which is why compilers expose target flags such as -march=armv8.2-a.
| Version or extension | Key additions | Typical use |
|---|---|---|
| Armv8.0-A | AArch64 state, NEON, optional crypto | First 64-bit Arm phones and servers |
| Armv8.1-A to 8.3-A | Atomic instructions (LSE), pointer authentication | Scalable servers, exploit hardening |
| SVE | Scalable vectors from 128 to 2,048 bits | High-performance computing |
| Armv8.5-A | Memory tagging extension (MTE), branch target identification | Memory safety debugging and hardening |
| Armv9-A | SVE2 as baseline, confidential compute architecture | Current phones, laptops and servers |
| SME | Scalable matrix extension | On-CPU matrix math for AI workloads |
Pointer authentication and memory tagging are notable because they move security features into the instruction set. Pointer authentication signs return addresses to resist return-oriented programming, while memory tagging detects many use-after-free and buffer overflow bugs at run time.
ARM64 compared with x86-64 and RISC-V
ARM64, x86-64 and RISC-V are the three instruction set architectures that dominate general-purpose computing discussions. The differences that matter most are instruction encoding, licensing and software ecosystem, not raw speed, because performance depends on the microarchitecture rather than the ISA alone.
| Aspect | ARM64 | x86-64 | RISC-V (RV64) |
|---|---|---|---|
| Design style | RISC, load-store | CISC, register-memory | RISC, load-store |
| Instruction length | Fixed 32 bits | Variable, 1 to 15 bytes | 32 bits, optional 16-bit compressed |
| General-purpose registers | 31 | 16 (32 with APX) | 31 plus hardwired zero |
| Licensing | Commercial licenses from Arm | Effectively Intel and AMD only | Open, royalty-free standard |
| Software maturity | Very broad, mobile and server | Broadest desktop and legacy base | Growing, strongest in embedded |
A frequent misconception is that ARM64 chips are efficient simply because they are RISC. Modern x86-64 cores translate instructions into internal micro-operations, so the gap is smaller than the labels suggest. ARM64 does gain from simpler decoding and a long focus on low-power designs, and vendors have exploited this in laptop and server chips with high performance per watt.
Where ARM64 runs and how software adapts
ARM64 is the standard architecture for Android and iOS devices, Apple silicon Macs, Windows on Arm laptops including Copilot+ PCs, Arm-based cloud instances and many single-board computers. Operating systems identify it with different names: arm64 in Apple and Windows tooling, aarch64 in Linux distributions and compilers.
Running existing x86-64 software requires either native recompilation or binary translation. Translation layers such as Rosetta 2 on macOS and Prism on Windows convert x86-64 code to ARM64 at install or run time, usually with acceptable overhead for applications but weaker results for some games, anti-cheat systems and kernel drivers, which cannot be translated and need native ARM64 builds.
| Situation | Recommended approach | Reason |
|---|---|---|
| Open-source application | Recompile natively for aarch64 | Best performance, usually minor changes |
| Closed-source desktop app | Use emulation, request native build | Translation works for most user-mode code |
| Device driver | Obtain a native ARM64 driver | Kernel code is not emulated |
| Containers in the cloud | Publish multi-architecture images | Same tag runs on Arm and x86 hosts |
Common pitfalls with ARM64
- Confusing ARM64 with a chip: the name describes the instruction set, not a specific processor or level of performance.
- Assuming identical feature sets: SVE, MTE and crypto extensions are optional or version dependent, so code needs runtime feature detection.
- Memory ordering bugs: multithreaded code that silently relied on the stronger x86 ordering may fail on ARM64 without proper atomics.
- Mixing 32-bit and 64-bit Arm: AArch32 is a separate execution state, and many recent cores no longer run 32-bit Arm code at all.
In simple terms
Think of ARM64 as a shared language that processors speak. Many different companies build processors, but if they all understand ARM64, the same app can run on all of them, much as many people with different accents can read the same book.
This language was designed to be simple and efficient, which is why it powers almost every smartphone and a growing number of laptops and servers. The language itself does not decide speed; the quality of each company’s processor design does.
A practical example
A software team runs its web API on a fleet of x86-64 cloud servers. To reduce costs, it tests the same service on ARM64 cloud instances. The code is written in a language with a mature aarch64 compiler, so the team rebuilds it and publishes a multi-architecture container image that contains both builds under a single tag.
During testing, one native library fails because it uses hand-written x86 vector instructions. The team switches to a version with ARM64 NEON support. After load testing shows similar response times with lower cost per request, the team moves most of its traffic to the ARM64 instances while keeping a small x86-64 pool as a fallback.