Linus Torvalds (torvalds@linux-foundation.org) on 1/12/11 wrote:
---------------------------
>Wilco (Wilco.Dijkstra@ntlworld.com) on 1/12/11 wrote:
>>
>>There is full compatibility between the different ARM cores, you can run a binary
>>compiled for one architecture on any other CPU of the same architecture or higher.
>
>You're basically weaselwording, and judging from your other
>posts over the years, you're so deep in denial that you
>probably even believe it.

Look, I was one of the people involved in this for a decade, so I know everything there is to know about ARM. Now if you want to claim to know better, then you've got to show some hard evidence.

>NEON and even just VFP is still "optional" even in a modern
>Cortex-A9. ARM is years away from having something you can
>rely on in that area.

VFP isn't optional since ARMv7. Neon is indeed optional as it almost doubles the size of an ARM core. You can rely on it in certain ecosystems, for example I'd guess it will be mandated in Windows on ARM.

In the case you don't know whether Neon is supported or not, you can still provide the same API (eg. to decompress an image). The DLL which implements it can use Neon if available, a GPU or any other special purpose hardware - basically the OS can hide much of this. And in specific cases you can resort to runtime checks if you like. All this is pretty standard stuff, and you can hardly claim this sort of thing isn't widely used in the x86 world.

>So yeah, you can run one binary, if you end up really
>catering to the lowest common denominator. And that's just
>the user-space side.

Nope. Does everybody still use only 8086 opcodes (which is the lowest common denominator amoung x86)?

>The disaster when it comes to crazy
>and bad system design (virtual caches? Seriously?) is just
>sad. The unaligned accesses are another kind of sad.

Virtual caches have long been obsoleted. They are fine for simple micro kernels but not suitable for big OSes. And unaligned accesses have been supported in most ARM cores for many years.

>At least x86 never had that kind of crazy.

Come on, do I really need to remind you of x87, HIMEM, DOS, 16-bit and all that crap? Did you actually use PCs since the early days? Anyone who did knows how ridiculously backwards and primitive x86 was compared to the RISC workstations (ARM, SPARC, MIPS, IBM-RT, HP-PA) we used at that time.

>And yes, Atom is on the verge of being out-performed by
>ARM, but my point about performance was that Atom is about
>an order of magnitude slower than the desktop offerings.
>So "it competes with Atom on performance" is not the same
>as "it can compete with x86 in general".

Atom isn't a magnitude slower, unless you compare with the highest end multicore CPUs. You're quite right today ARM can't compete with high-end x86. But that was never the aim. My point is that ARM's performance is improving much faster than x86, so it is rapidly closing the gap with high-end x86. Whether we see eg. NVIDIA taking on high-end x86 head-on is another matter. Typically the best approach is to attack from below and not head-on.

>And again - don't get me wrong. I like ARM. I think it has
>a chance to be king. But I dislike your kind of rabid
>fanboism. Some realism about the shortcomings, please.

That's exactly why I want to stick to the hard facts and don't like false claims.

Wilco