name99 (name99.delete@this.redheron.com) on November 17, 2012 3:40 pm wrote:
> I think the point about allowing implementations flexibility is VERY important,
> and thus means ARM want to make as little compulsory in the ISA as possible.
>
> Take Apple as an obvious example. Given their track record, a very obvious strategy for them would be to ship
> the Swift-64-A (or whatever they call it) with 32-bit support and ALSO to tell their iOS developers "you have
> ONE, hear that, ONE year to convert your code to 64-bit". Then, Swift-64-B simply tosses 32-bit support overboard,
> to the relief of the designers, and allowing them rather more freedom in future designs.
>
> Apple has, remember, astonishingly high rates of uptake of new OSs and new app versions, they
> control XCode, and they can easily do things like refuse to allow new code in the App store
> that doesn't come with both a 32-bit and 64-bit binary. They can even do things like, at app
> install/update time, strip out the unnecessary binary so as not to waste flash.
>
> MS apparently could do the same thing with Win RT, but historically they have not
> had their act together enough to do so. Android..., yeah, good luck with that.
>
> Meaning is: you have one partner that REALLY wants to ditch 32-bit ASAP, and other partners
> that want to keep it for a long time. It makes no sense for ARM to privilege one of these
> over the other. (And they will undoubtedly benefit from the halo if Apple CAN use ditching
> 32-bit to make a chip that's substantially faster, and makes ARM as a whole look good.)


I agree with you that Apple will have a much easier time converting to 64 bit ARM. Not only for the reasons you suggest about extremely high OS update rates, control of the dev environment and app store, etc. but also because they have no low end market.

Android OEMs can't just switch to 64 bits overnight because while they sell plenty of Galaxy S3s and the like, the market for low end phones is larger than the market for high end phones. That's because most of the recent growth and almost all the remaining growth in the smartphone market is from people upgrading their cheap feature phone to a cheap smartphone. They will have no choice but to sell these people low end phones, because they can't afford/don't want to pay for high end phones. So they'll have to support 32 and 64 bits simultaneously for quite a while, until the added cost of a 64 bit CPU is essentially zero.

I believe you also overlook one thing in the argument you seem to be making that Apple wants 64 bit ASAP while Android OEMs are in no hurry. Apple won't go 64 bit until they have a reason to, and that reason will be dictated by wanting to put >4GB in a device. I think they're a few years from doing that on iPad, let alone iPhone. I don't think there's anything inherent in ARM64 that would result in faster processors, unlike in the x86 world where the additional registers were a big deal for such a register starved chip in its 32 bit form. Apple isn't going to introduce a new model and tell its customers they should buy it simply because it has a 64 bit CPU, unless that 64 bit CPU translates into some benefit to the user experience they can point to "it is good at xxx because it has a 64 bit CPU".

On the other hand, Android vendors, all using nearly identical software, have to compete with each other almost exclusively on the basis of hardware, and thus have reason to switch to 64 bits - even if they don't need it. After all, they're shipping phones with four cores now, which is pretty pointless for a phone. They'll be falling all over themselves trying to be the first to market with a 64 bit phone, and market it as a must have feature in a high end phone, like they are doing today with quad core CPUs.