On Thursday, ARM took the wraps off its long awaited 64-bit version of the ARM instruction set architecture (ISA). Called ARMv8, the new extensions will put ARM squarely in competition with Intel in the server and desktop markets. It’s important to note that ARM’s move to 64 bits isn’t about performance—rather, it’s strictly about giving ARM-based platforms the ability to cleanly and efficiently address more than 4GB of usable memory. In exchange for 64-bit support, ARM will be giving up a bit of power efficiency, which indicates that the initial batch of chips based on ARMv8 will be targeted not a mobiles but at the aforementioned servers and desktops.
The main mobile application for 64-bit ARM will be the forthcoming ARM-based Windows tablets. Neither Microsoft nor its third-party developers will want to have a 32-bit/64-bit split between its desktop and tablet OS, so the Windows ARM port will be 64-bit from the start. Indeed, it’s likely that ARM’s commitment to announcing a 64-bit version of its architecture was necessary before Microsoft even agreed to the Windows port.
Given that this 64-bit move was made in large part with Microsoft in mind, it’s no surprise that Microsoft was on-hand to provide supporting quotes for ARM’s v8 announcement. NVIDIA was also there for the announcement, and the chipmaker hopes to position its forthcoming ARM-based CPU family as the premier way to run Windows on ARM. The GPU powerhouse makes no secret that it is openly going after Intel in the desktop, high-performance CPU space with its ARM family of general-purpose microprocessors.
64-bit costs and benefits
As was the case with AMD’s (and later Intel’s) 64-bit extensions to x86, ARMv8 will effectively be a superset of ARMv7. All ARMv8 chips will run legacy 32-bit ARMv7 code in the AArch32 execution state, while 64-bit code will be run in the AArch64 state.
The present ARM architecture has a maximum integer size of 32 bits, and older ARM chips could store and operate on memory addresses that are up to 32 bits wide. Because computers use the base-2 binary number system, then the largest number that can fit into one of ARM’s 40-bit registers (a register is a small bit of memory on the chip) is 232, or little over 4 billion. So a computer with a 32-bit register file can “see” and manipulate no more than 4 billion bytes, or 4 GB, of memory.
In 2010 ARM announced a 40-bit virtual memory extension for ARM v7, which uses a two-stage address translation to get around the 4GB memory limitation. This kind of sleight-of-hand isn’t nearly as ideal, however, as a clean 64-bit implementation of the type that ARM is announcing with v8.
By widening the integer registers in its register file 64 bits, ARM v8 can store and operate on memory addresses in the range of millions of terabytes. Of course, in the near and medium term it won’t be feasible to build machines with such large memory capacities, and in reality even current 64-bit systems from Intel and AMD don’t support such large amounts of memory as a practical matter. But the move to 64 bits will put ARM on a more equal footing with x86 by removing future barriers to growth. (For more on the difference between 32-bit and 64-bit computing, see An Introduction to 64-bit Computing and x86-64.)
ARM’s 64-bit parts will pay a price in power efficiency for the boost to memory capacity and forward compatibility. The wider register file uses more logic and power on the die, and the wider integers and addresses will increase internal and external bus traffic. At the level of a desktop or server microprocessor, the power cost of these two items will be completely negligible. But in the sub-milliwatt regime where many of ARM’s mobile chips operate, there would be no reason to pay a power penalty for an increased memory capacity that won’t be used anyway. (Mobiles won’t yet need more than 4GB of memory, and won’t for the foreseeable future.) So except for chips aimed at tablets and laptops, ARM’s mobile offerings will likely stay 32-bit for quite a long time.