(→Exceptions) |
(→Overview: ham) |
||
Line 2: | Line 2: | ||
'''AArch64''' is the {{arch|64}} execution state of the {{\\|ARMv8}} ISA. A machine in this state executes operates on the {{\\|A64}} instruction set. This is in contrast to the {{\\|AArch32}} which describes the classical 32-bit ARM execution state. | '''AArch64''' is the {{arch|64}} execution state of the {{\\|ARMv8}} ISA. A machine in this state executes operates on the {{\\|A64}} instruction set. This is in contrast to the {{\\|AArch32}} which describes the classical 32-bit ARM execution state. | ||
+ | [[File:awad|67px|frame|none|Kam]] | ||
== Overview == | == Overview == | ||
The AArch64 execution state was introduced with the {{\\|ARMv8}} ISA for machines executing {{\\|A64}} instructions. A machine in AArch64 can only execute A64 instructions and cannot execute {{\\|A32}} or {{\\|T32}} instructions. However, unlike in {{\\|AArch32}}, in the 64-bit state, instructions can access both the 64-bit and 32-bit registers. | The AArch64 execution state was introduced with the {{\\|ARMv8}} ISA for machines executing {{\\|A64}} instructions. A machine in AArch64 can only execute A64 instructions and cannot execute {{\\|A32}} or {{\\|T32}} instructions. However, unlike in {{\\|AArch32}}, in the 64-bit state, instructions can access both the 64-bit and 32-bit registers. |
Revision as of 01:24, 20 February 2019
ARM ISA | |
General | |
Variants | |
Extensions | |
Topics | |
Versions(all) | |
AArch64 is the 64-bit execution state of the ARMv8 ISA. A machine in this state executes operates on the A64 instruction set. This is in contrast to the AArch32 which describes the classical 32-bit ARM execution state.
Overview
The AArch64 execution state was introduced with the ARMv8 ISA for machines executing A64 instructions. A machine in AArch64 can only execute A64 instructions and cannot execute A32 or T32 instructions. However, unlike in AArch32, in the 64-bit state, instructions can access both the 64-bit and 32-bit registers.
Calling convention
- See also: ARM's Calling convention
Under AArch64, the first eight registers are used for passing parameters into a subroutine as well as to return a result value set. Generally, X0 through X18 can corrupt while X19-X29 must be preserved.
Register | Role | Requirement |
---|---|---|
X0 - X7 | Parameter/result registers | Can Corrupt |
X8 | Indirect result location register | |
X9 - X15 | Temporary registers | |
X16 - X17 | Intra-procedure call temporary | |
X18 | Platform register, otherwise temporary | |
X19 - X29 | Callee-saved register | Must preserve |
X30 | Link Register | Can Corrupt |
Exceptions
Generally, exceptions in AAarch64 is very similar to AArach32. There are four exception levels (ELn): EL3 - EL0 with EL0 being the least privileged level (application) and getting progressively more privileged than the one below it. Exceptions always go to the same level or a higher level but they can not take you to a lower level. When taking an exception, the exception link register (ELR) associated with the target exception level is written on exception entry and the interrupt masks are also set. Entering AAarch64 from AAarch32, the ELR is always zero-extended. AArach64 banked registers are banked by exception level, meaning none of the regular (both GPRs and media) are banked. In AArach64, most of the old mechanism found in AAarch32 was not necessary because, at any exception level, it's now possible to simply use the dedicated stack pointer. Additionally, the exception link register (ELR) can be used to determine the origin address. This significantly simplifies exceptions under 64-bit operating mode.
EL0 | EL1 | EL2 | EL3 | |
---|---|---|---|---|
Stack Pointer | SL_EL0 | SP_EL1 | SP_EL2 | SP_EL3 |
Exception Link Register (PC) |
ELR_EL1 | ELR_EL2 | ELR_EL3 | |
Saved/Current Process Status Register (CPSR) |
SPSR_EL1 | SPSR_EL2 | SPSR_EL3 |
Each exception level except for EL0 has its own vector table. The vector in AAarch64 was designed to provide additional information about the exception type (sync, IRQ, FIQ, error) and origin (EL and register width, and stack pointer info), eliminating the need to check the syndrome register which was also significantly enhanced to include a more complete classification of exceptions. It's worth noting that the entry in the table was increased from 4 bytes to 32 instructions long (0x80 bytes), meaning instead of just storing the branch, it's now possible to store the handler directly when it is advantageous to do so.
MMU
The Large Physical Address Extension (LPAE) on ARMv7 is largely a precursor to the ARMv8 changes. Under AArch64, the virtual address space for each TTBR can be up to 48 bits. This is supported at run-time with lower values benefitting from a smaller table walk. The upper 8 bits of the address is ignored for the purpose of address translation, allowing software to use it for tagged pointers. The physical address space was also defined to support up to 48 bits.
The supported granule sizes are 4 KiB, 16 KiB, and 64 KiB. This corresponds to the size of the smallest page supported as well as the size of the translation tables in memory. Which of the three supported is up to the implementation.
Other features
- Top-byte Ignore (TBI)
Bibliography
- Richard Grisenthwaite. (October 26, 2011). "Technology Preview: The ARM Architecture - a View of the Future ".
- ARM Architecture Group. "Armv8 instruction set overview." vol. PRD03-GENC-010197 (2011).