Why a 64-bit iPhone?
By: . Published: . Categories: iphone arm.Apple announced a couple days ago an iPhone with a 64-bit processor.
Some people worried because their code was unclean. Those people should read Compatibility Basics and follow it up with a strong draught of Apple’s 64-Bit Transition Guide from the last time Apple transitioned a platform from 32- to 64-bit.
Some people wondered why bother. “It’s just about the RAM, innit? Who’s gonna put that much blasted RAM in a mobile device?”
Well, someone will, and sooner rather than later. But regardless of that, there are other reasons to go 64-bit.
We hear and remember “we’re going 64-bit”. But it’s not just a word width change: it’s a whole shift in processor, ABI, and, in general, a chance to make a clean break from the past.
A prime motivation behind moving from x86 to x86_64 was how tremendously register-starved x86 was.
ARM isn’t exactly register-starved, but it’s got some rough edges. Nowhere near as rough as the Intel lineage, but rough nonetheless.
Transitioning to 64-bit gives ARM that same opportunity. Only they weren’t forced into it so soon, so they got to watch how everyone else tried (and failed, and retried) to do it.
I’m no great guru of ARM, so I will instead direct you to the August 2012 write-up by Mr.\ David Kanter over at Real World Technologies, ARM Goes 64-bit for details.
The key bits for me are:
- More registers.
- Bigger registers.
- Yup, even the vector registers get bigger and more numerous.
- Simplifications that make it easier for those of us coming from Intel-land:
- The end of conditional suffixes on all the instructions.
- Load/pop multiple replaced by load/store pair.
- An exception-level system that more closely resembles the ring-system and replaces the far more complicated eight (!) processor modes of ARMv7.
- A memory model and corresponding instructions that jive well with the memory model and atomic operation support in the most recent revisions of C++ and C.
- And yes, we can now directly address more RAM with a simple index. Nothing like PAE or manual DOSseriffic segment-indirection needed.
Though it’s less RAM than you might naïvely think:
Currently, AArch64 features two 48-bit virtual address spaces, one for the kernel and one for applications. Application addressing starts at 0 and grows upwards, while kernel space grows down from 2^64; any references to unmapped addresses in between will trigger a fault. Pointers are sign extended to 64-bits, and can optionally be configured to use the upper 8-bits for tagging pointers with additional information. (“Virtual Address Space”)
(I’d point you at the horse’s mouth, but as of this time, almost all the ARMv8 docs are only available for those cosy with ARM, not us plebs. An exception is the ARMv8 64-bit architecture overview, which provides a concise one-pager of a description of the changes from ARMv7.)