OSNews

You can actually run code from PPC to x86 or vice versa using advanced binary translation, dynamic recompilation or emulation. You get a 4x speed slowdown on average with dynamic recompilation, that would be less if the code was recompiled with binary translation. In fact, in some tests, binary translating from x86 to x86 for hotpaths and some simple optimisations gives a modest speed increase (maybe 5-25%) say in the Dynamo-RIO system.

Basically, x86 is garbage. It hangs around like a bad smell to cause misery to programmers and holds people back from real improvements. It's a wonder Intel keeps up, basically their CPU's are RISC-like underneath with a shockingly bad x86 architecture thrown on top. I'd imagine if a better, more reliable architecture turned up that everyone suddenly jumped onto Intel could probably rewrite the microcode to run it in a matter of weeks on their existing chips if they wanted to support it (and it was supported).

The main issue with legacy code isn't the architecture - it's the API calls and OS calls that make it a problem. Look at Wine - taken years to rewrite most of the Windows APIs. Executor got a good chunk of the way on the MacOS API's. GNUStep a good effort at OpenStep.

The fact is the different OSes refuse to play ball with each other API or driver wise. EFI -may- resolve some of the low level hardware problems, but as other people (like Linus et al) are saying, it's too hard as it reminds them of something they didn't like (a long long time ago... maybe in a distant galaxy far far away).

Guys like SciTech Solutions (http://www.scitechsoft.com/products/dev/sdk_home.html) are doing a pretty good job of cross-platform drivers (notably video and audio). If a small company can get the job done, just think what Microsoft, Apple and GNU/Linux developers could do with the right incentives.