bakaneko (nyan.dont.delete@this.hyan.wan) on August 14, 2012 4:21 am wrote:
> anon (anon.delete@this.anon.com) on August 14, 2012 2:37 am wrote:
> > Do you know if
> > implementations are going to execute 32 bit ARMv7 code at full speed? In that
> > case, won't predication shifting and addressing etc still complicate execution?
> > What's the plan there?
>
> Good question, it begs for microcode in 32bit mode. That way
> 32bit code would be as fast as the 64bit code which uses
> multiple instructions + overhead for microcode (if any).
>

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.)