Overview
The ARMv8 architecture is a relatively elegant and compatible with ARMv7 for Application processors (i.e. A-profile) targeted at general purpose workloads. The most significant aspect of ARMv8 is the addition of a new 64-bit instruction set to complement the existing 32-bit ISA. The new instructions are known as A64 and operate on the AArch64 architectural state. ARMv8 also comprises A32 and T32 (for Thumb) and AArch32, which are backward compatible with ARMv7. However, the A64 instruction set is entirely separate and actually uses a slightly different format and new decoding tables.
ARMv7 is undeniably a RISC instruction set, but it has quite a few rather unattractive features that both clash with the ideals behind RISC and complicate real implementations. This is hardly surprising, as most RISC architectures had particular quirks that stemmed from history and ARM is no different. Many of the oddities in ARM are a result of the focus on embedded computing, e.g. banked registers for fast interrupt handling.
While ARMv8 is intended to be backwards compatible, A64 is moderately different from the existing 32-bit ARM architecture. A64 both adds capabilities and also eliminates some of the more obnoxious aspects of the architecture. Some of the new enhancements in A64 are applicable to A32, so software written for AArch32 is not compatible with ARMv7 implementations. Likewise, some instructions have been removed in AArch64 that may impact ARMv7 code – although these changes are unlikely to impact most software.
ARM targeted two data models for the 64-bit mode, to address the key OS partners. The first is LP64, where integers are 32-bit, and long integers are 64-bit, which is used by Linux, most UNIXes and OS X. The other is LLP64, where integers and long integers are 32-bit, while long long integers are 64-bit, and favored by Microsoft Windows.
One of the more substantial changes in AArch64 is the new exception and privilege model. AArch64 includes 4 Exception Levels (0-3), which replaces the 8 different processor modes found in ARMv7. EL0 loosely corresponds to user-mode, EL1 to kernel-mode with EL2 for hypervisors and EL3 for ARM’s TrustZone security monitor. EL3 is the most privileged, with EL0 as the least. The new privilege model is much simpler and relatively similar to existing approaches, such as x86 ring.
Figure 1. ARMv8 Privilege Model, courtesy ARM
As with other 64-bit ISAs, there is a high degree of inter-operability, as shown by Figure 1. AArch64 hypervisors and/or OSes can support AArch32 at lower privilege levels (e.g. AArch32 guest OS on a AArch64 hypervisor or AArch32 apps on an AArch64 OS). However, higher privilege levels cannot be in AArch32 if lower levels are AArch64 (e.g. AArch64 OS on AArch32 hypervisor is not valid).
Transitions between AArch32 and AArch64 can only occur at exceptions and exception returns. For backwards compatibility, AArch32 still retains the rather complicated ARMv7 exception model which features 8 different privilege modes.
ARM’s approach of separate ISAs for compatibility is a contrast to Intel and AMD’s solution with x86, where the newer modes are truly an extension of the existing architecture. In x86, older 16-bit and 32-bit instructions are essentially a subset of the newer 32-bit and 64-bit operating modes. An extended ISA allows mixing new and old code more seamlessly. However, separate ISAs are necessary to eliminate the older exception model in ARMv7 and move to the newer and more elegant system in AArch64.
The one surprise in ARMv8, is the omission of any explicit support for multi-threading. Nearly every other major architecture, x86, MIPS, SPARC, and Power has support for multi-threading and at least one or two multi-threaded implementations. While initially billed as a technique for servers, it is helpful for a variety of software. However, multi-threading is very difficult to validate, and the engineers at ARM may have simply felt that handling the transition to a 64-bit architecture was challenging enough. Certainly, should the lack of multi-threading become a significant competitive disadvantage, it can be added in the future.
Pages: « Prev 1 2 3 4 5 Next »
Discuss (195 comments)