Wilco (Wilco.Dijkstra@ntlworld.com) on 1/14/11 wrote:
>
>The situation on x86 is that CPU 1 implements instructions 1-20, CPU 2 implements
>1-30, CPU 3 implements 1-50 but not instruction 10, CPU 4 does 1-75 but not instruction 20 and so on.

Umm. Let me speak from some experience here.

It's pretty much trivial to cover the whole x86
spectrum with two kernel binaries: one for 32-bit space,
and one for 64-bit. That's what every single Linux distro
does these days (there might be two: historically we used
to do SMP and UP separately, and if you want to support
i386-class machines you still want to do it, but I don't
think people do).

So your "x86 instruction set fragmentation" argument is
pure and utter bullsh*t. Yes, there are options, but they
are not hard to handle, and people have left some of them
behind.

ARM, on the other hand? Not so much. And the ARM instruction
set is just the tip of the pain iceberg. Going at all away
from the CPU core, you get into a whole another dimension
of pain.

The fact is, Wilco, that ARM is much harder to
handle from a fragmentation standpoint. Contrary to your
wild theories.

ARM is only easy if you work purely in user space and do
nothing interesting (ie no FP optimization issues, no
virtual mapping issues, no threading, no nothing). Then you
only have a couple of gross cases to worry about. But even
then you do have a couple of cases.

Of course, I get the feeling that you're a compiler person.
So you'd never see or care about the problems I am talking
about, because they are all "undefined behavior" as far as
you're concerned.

Linus