The 64-bit version of the ARM architecture is formally known as AArch64. It is the 64-bit version of classic 32-bit ARM, which has been retroactively renamed AArch32.<\/p>\n
Even though the architecture formally goes by the name AArch64, many people (including Windows) call it arm64. Even more confusing, the instruction set is called A64. (The 32-bit ARM instruction sets have also been retroactively renamed: Classic ARM is now called A32, and Thumb-2 is now called T32.)<\/p>\n
AArch64 differs from AArch32 so much that I’m going to cover it fresh rather than treating it as an extension of AArch32. That said, I will nevertheless call out notable points of difference from AArch32.<\/p>\n
No more Thumb mode<\/b><\/p>\n
AArch64 is an extension of the classic ARM instruction set, not an extension of Thumb-2. So we’re back to fixed-size 32-bit instructions (aligned on 4-byte boundaries). No more gymnastics with low registers and high registers, or using non-intuitive instructions to avoid a 32-bit encoding, or remembering to set the bottom bit on code addresses to avoid accidentally switching into classic mode.<\/p>\n
A note for those familiar with the classic ARM instruction set: One thing that did not get carried forward was arbitrary predication. The answers to this StackOverflow question dig into the reasons why predication was removed<\/a>. Short version: Predication is rarely used, it consumes a lot of opcode space, it doesn’t interact well with out-of-order execution, and branch prediction is almost as good.<\/p>\n Data sizes<\/b><\/p>\n The architectural terms for data sizes are the same as AArch32.<\/p>\n
| Term<\/th>\n | Size<\/th>\n<\/tr>\n | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| byte<\/td>\n | \u20078 bits<\/td>\n<\/tr>\n | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| halfword<\/td>\n | 16 bits<\/td>\n<\/tr>\n | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| word<\/td>\n | 32 bits<\/td>\n<\/tr>\n | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| doubleword<\/td>\n | 64 bits<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The processor supports both big-endian and little-endian operation. Windows uses it exclusively in little-endian mode. AArch64 lost the Aarch32 Registers<\/b><\/p>\n Everything has doubled. The general-purpose registers are now 64 bits wide instead of 32. And the number of such registers has doubled from 16 to 32<\/span> okay just 31. The encoding that would correspond to register 31 has been reused for other purposes. So not quite doubled.<\/p>\n The link register is architectural; the rest are convention.<\/p>\n You can refer to the least significant 32 bits of each 64-bit register by changing the leading x<\/var> to a w<\/var>, so we have w0<\/var> through w30<\/var>. If an instruction targets a w<\/var> register, the result is zero-extended to fill the x<\/var> register.\u00b9<\/p>\n Particularly notable is that the stack pointer sp<\/var> and program counter pc<\/var> are no longer general-purpose registers, like they were in AArch32. The registers still exist, but they are treated as special registers rather than being encoded in the same way as the other general-purpose registers.<\/p>\n In AArch64, the pc<\/var> special register reads as the address of the instruction being executed, rather than being four bytes ahead, as it was in AArch32. The extra +4 in AArch32 was an artifact of the internal pipelining of the original ARM and became a backward compatibility constraint even as the pipeline depth changed.<\/p>\n Windows requires that the stack remain 16-byte aligned, and it enables hardware enforcement of this requirement. The 32-bit subregister of sp<\/var> is called wsp<\/var>, although it is of no practical use. (The 64-bit register is still called sp<\/var>, not xsp<\/var>. Go figure.)<\/p>\n There is a 16-byte red zone below the stack pointer, but it’s reserved for code analysis. Intrusive profilers inject assembly language fragments into compiled code to update profiling information, and they need some space to store two registers so they can free up some registers to do their profiling work.<\/p>\n The xip0<\/var> and xip1<\/var> registers are volatile because they are used to assist with branch instructions that try to branch to an address that is out of range. We’ll see later that these registers are also used by function prologues and epilogues.<\/p>\n There is a new xzr<\/var> pseudo-register (and its 32-bit alias wzr<\/var>) which reads as zero, and writes are ignored. As I noted in the above table, if an instruction encodes a register number of 31, then a special behavior kicks in, typically by treating mythical register 31 as an alias for sp<\/var> or zr<\/var>. Generally speaking, when being used as a base address register, imaginary register 31 represents sp<\/var>, but when used for arithmetic or as a destination register, it represents zr<\/var>.\u00b2<\/p>\n In instruction descriptions, I will use these shorthands:<\/p>\n The floating point registers have been reorganized. They have doubled in size (to 128 bits) as well as in number, and the single-precision registers are no longer paired up.<\/p>\n Each floating point register can be viewed in multiple ways. The partial registers are stored in the least significant bits of the full register.<\/p>\n The flags register is formally known as the Application Program Status Register (APSR). The flags available to user mode are the same as in AArch32:<\/p>\n The overflow flag records whether the most recent operation resulted in signed overflow. The saturation flag is used by multimedia instructions to accumulate whether any overflow occurred since it was last cleared. The GE flags record the result of SIMD operations. By convention, flags are not preserved across calls.<\/p>\n There are a number of AArch64 features that you are extremely unlikely to see in Windows code, such as tagged pointers, tagged memory, and pointer authentication, so I won’t cover them here. I also won’t cover floating point instructions or SIMD instructions.<\/p>\n Next time, we’ll look at some of the weird transformations that can be performed inside an instruction.<\/p>\n Additional references<\/b>:<\/p>\n |