It’s been a year since ARM announced the first details of the new ARMv8 architecture with its support for 64-bit virtual addressing. This comparatively early announcement allowed the architecture to be discussed publically, and more importantly be worked on within the open source community. This strategy paid off, and recently both the mainline Linux kernel approved the inclusion of the AArch64 support from version 3.7, and the GCC tools support from version 4.7 With the discussion now moving onto actual implementations, and then onto devices arriving in market, it’s probably a good time to spend a few lines to talk about why this step change in capability is happening, and the likely impact it’s going to have across the billions of devices that will be using this technology in the next few years. As you’ve probably just seen, ARM announced its new ARM® CortexTM-A50 series of processors supporting this new ARMv8 architecture too.
Let’s first recap what ARMv8 is, and how it differs to the architecture support in the current Cortex-A series processor. The current processors unsurprisingly support the ARMv7 architecture, and the most important thing to know about these Cortex-A50 processors is that they still fully support all the software written for the ARMv7 processors through the ARMv8 architecture’s inclusion of an AArch32 state, an execution state which is fully backwards compatible with ARMv7.
It’s this union of the AArch32 and AArch64 processor states that makes ARMv8 most interesting. Historically, processor architectures as they moved to support 64-bits took one of two directions; they either created a brand new architecture excluding any efficient legacy mode, or they added 64-bit within the existing 32-bit architecture which simply drove complexity and inefficiencies even higher. With ARMv8 supporting both a fully performant legacy mode, and a new clean 64-bit design, implementation can maximize the power efficiency of both states while providing an incremental roadmap for software to adopt the new capabilities at the rate any specific market requires.
In supporting this incremental roadmap for the software adoption of AArch64 and the associated 64-bit processing, it opens new markets to ARM architecture-based solutions while also providing other markets the confidence in their long term roadmap and support of the new features and capabilities as their specific market evolves. For example, within various networking and enterprise markets, the need for applications to address more than 2 or 3GB of RAM is here today, and it will be these markets which will immediately adopt the AArch64 state of a given implementation. Some partner implementation where there is no legacy software as such within a specific mode of the processor, may decide to remove support of the AArch32 state from their implementation and provide support for 64-bit only.
Other device markets such as tablets and smartphones will likely take a much more gradual, although progressive move through to 64-bit only support. Despite the number of historical statements that suggest “computing will never need more than <x>” [insert your favourite example], few can say mobile will never need 64-bit. It’s clear that the Cortex-A15 and Cortex-A7 inclusion for support of Large Physical Address Extension (LPAE) and its ability to support up to 40bits of physical memory provides mobile the ability to support more than the current 4GB limit of a device today by allowing each application to address their own 4GB of memory. However, what is often forgotten is that the operating system is also still limited to a 4GB address space, and as memory increases, the OS can also run out of address space as the physical memory of a device continues to increase or the number of running applications increases.
The lead of the OS ‘running out of memory’ before applications will likely be the first example of how mobile will start its journey into 64-bit support. The ARMv8 architecture has a very clean and well architected approach to allow the operating system to run within the 64-bit virtual address mode of AArch64, while the user application space can all still run in the AArch32 state. This gives a solution which is the best of both worlds; the ability to run an effectively unlimited number of full performance 32-bit user applications, with the operating system efficiently operating in the AArch64 bit mode of the ARMv8 device. Within ARM for example, we have demonstrated the current Android™ release running unaltered on a full AArch64, 64-bit Linux kernel. This split state capability provides the low risk roadmap required by any market which develops any need to incrementally move over to 64-bit computing.
If you’d like to read more about the capabilities of the ARMv8 architecture, please take a look at my white paper or the technology introduction video.