Richard Cownie (tich@pobox.com) on 1/14/11 wrote:
---------------------------
>Linus Torvalds (torvalds@linux-foundation.org) on 1/14/11 wrote:
>---------------------------
>
>>The fact is, Wilco, that ARM is much harder to
>>handle from a fragmentation standpoint. Contrary to your
>>wild theories.
>
>I daresay this is correct at the moment. But the next
>couple of years will surely see two de facto ARM
>standards emerging: ARM implementations that can run
>Android effectively; and those that can run Windows8
>effectively. The existence of those two fairly
>demanding software platforms - each of which will also
>support thousands of apps - is going to make a big
>difference. If you're designing a new (high-end) ARM,
>you almost certainly want it have all the features that
>Android and Windows8 want to use; and you almost certainly
>don't want to waste effort and silicon on features that
>those platforms *don't* use.

One thing I haven't seen mentioned here is that ARM is still lacking a 64 bit implementation. If ARM wants to grow upward, it will need 64 bit support. In the cell phone market this currently isn't an issue but in a couple of years handset makers will also want to break the 4 GB barrier. In the market ARM wants to grow into, 4 GB is already too small. I see ARM's PAE-like extensions as a stop gap solution for a real 64 bit announcement. I'm hopeful that ARM will make their 64 bit implementation a bit forward thinking to provide a far more unified platform in the future. This is ARM's golden opportunity and if they botch this, they never grow into Intel's territory.

Almost as important as the 64 bit definition is what 32 bit extensions will be supported as a subset for legacy support. 32 bit will hang around in the smart phone sector but the current players invested in an application centric market will not veer from this definition due to the inevitable 64 bit transition.

The other embedded niches ARM has become dominate in will continue to mutate on their own with extensions suiting their needs. Legacy support there is not critical and in many cases native 64 bit addressing is overkill.

>Even in the x86 space we've seen a cycle of Intel and AMD
>adding new incompatible features (MMX, 3DNow!, SSE,
>AMD64, virtualization) and then tending to converge on
>very similar functionality, and often even totally
>compatible implementations.

This is what worries me about the x86 space right now. There is AVX, SSE5, LNI which at some point were all incompatible with each other. AMD and Intel have unified their SSE5 and AVX extensions to make SSE5 a superset to AVX. With the first iteration of Larrabee not seeing the light of day outside of select research labs, there is hope that LNI will be depreciated and replaced by even newer Larrabee instructions that are a super set of AVX. I'm hoping that the ARM threat makes Intel and AMD take the issue of cross compatible x86 extensions seriously.