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.
John Goodacre, Director of Technology and Systems, ARM. John joined ARM in February 2002 and took responsibility for their platform architecture. Today he is Director of Program Management focused on various programs around the application processor’s technology roadmap including the definition and market development of the ARM MPCore multicore processor technology.
Prior to working at ARM, he specialized in enterprise software having worked for Microsoft for 5 years, firstly as Group Program Manager in the Exchange Server group and latterly as the manager of a team developing mobile phones software.
Graduating from the University of York with a BSc in Computer Science, John has over 20 years experience of realizing new technologies in the engineering industry.
0 Comments On This Entry
Please log in above to add a comment or register for an account
ARM Cortex-A57 Test Chip on TSMC 16nm FinFET Process Optimizes Tools & Flows
on Yesterday, 08:48 AM
Seven tips for ARM Accredited Engineer exam success
on May 20 2013 09:22 AM
The Server in Your Hand - and the three new interfaces inside it
on May 09 2013 08:54 PM
A DATE with Computing Destiny
on Mar 18 2013 06:57 PM
CDNLive Paper Preview: RTL Performance Analysis of ARM Interconnect IP
on Mar 11 2013 01:40 PM