No hint of it at all in their iOS betas. Extremely aggressive time to market. No competitor products announced for the smartphone or tablet form factors. Also represents a tremendous amount of R&D churn. It took them 3 years to pump out Swift as their first full custom chip and they're following it a year later with a new full custom chip on an entirely new ISA extension? Just seems improbable.
Hints in betas aren't much of a given, I don't think.. especially for something that can't even run on current hardware. Mind you, introducing 64-bit support into their CPU doesn't have to mean their OS is ready for it.
ARMv8 was announced nearly 2 years ago (October 2011). If you dig back further, nVidia's Project Denver was revealed way back in January 2011, so most likely they at least had good access to ARMv8 in 2010. That's a good three years, and meeting this in that timescale is not actually that aggressive - we're not talking about a full new custom design here, the changes mostly constitute new decoders, extended ALUs and data paths, and more architectural registers touched by the renamer (if it didn't already do so for the different mode banks).
I wouldn't expect the competitors to track simply because Android isn't going to really move on 64-bit until there's significant market coverage. Apple isn't restricted to that, they can drive their own OS however and whenever they please. That said, we don't really know what Qualcomm's plans are.
Helmore said:
Another thing, what motivation do they have to move to ARMv8 right now? I don't really see any benefits to it for Apple.
They need to have it done sooner or later. On some level they need the hardware before the software too, even for in-house software.
64-bit doesn't only become desirable once you want to surpass the 4GB wall. It's really better to have it once you move past as little as 1GB (incidentally, exactly where iOS is moving). If you don't have substantially more virtual address space than physical address space you start having to play games in the kernel with mapping windows into physical memory and I/O space. Linus Torvalds has talked a lot about this. I'm sure if Apple would like to be able to avoid this altogether if they can.
Do you remember the huge performance jump AMD64 had, even on 32 bit applications? I'm not saying the situation is directly analogous, but being able to address instructions twice the size each clock cycle is a big deal.
Let's be fair here, it's not like there was an AMD processor that only added 64-bit support and that's it.. so really not a lot to compare with. I can't see how a 64-bit processor running a 64-bit kernel would run 32-bit programs faster. Where x86-64 code provided a performance benefit it was almost entirely due to having more registers (from 8 to 16, both the scalar and SSE registers). The 64-bit addressing was rarely used as a performance benefit instead of just something you flat out need, and the 64-bit ALUs only really helped for a few niche applications. Without the extra registers programs would have generally ran slower because 64-bit pointers had worse cache pressure.
In ARM's case the new ISA does have some benefits (32 registers vs 16 and a few other things) but also some disadvantages, I doubt it'll get much performance from it, especially on big OoO cores that don't need a lot of extra registers for software renaming.
