Microsoft calls Intel's Windows 8 comments 'inaccurate'

Re: Serious question

No blondes here, I'm afraid. In the absence of self-modifying code, the translation you propose is trivial, it can be done once and thereafter the code behaves just like a normal ARM executable. You'd probably lose a few percent in performance on low-end chips, but on higher end CPUs the out-of-order execution would mean that you were actually bottlenecked on memory references rather than instruction execution and so performance would be indistinguishable from a native build.

In the presence of self-modifying code, you need to re-translate the modified code on the fly. In practice, such modifications are rare and confined to very short stretches of code, mostly generated by well-known libraries. It wouldn't be hard to handle them and you wouldn't notice the performance hit.

To elaborate on something I said in an earlier reply to someone else, when Microsoft were pitching Windows NT on all sorts of RISC platforms, they had a sub-system called FX!32 which let you run 32-bit x86 applications on the RISC-y Windows. In the case of the Alpha, FX!32 was so good that x86 apps ran faster on the Alpha than on the best Pentium chips of the time. (The Pentium Pro put paid to all that, and indeed to the entire RISC revolution, but that's another story.)

If Microsoft want Windows-on-ARM to be able to run x86 applications at full speed, they already have the code to do it. Intel know this. It is a credible threat to their business.

In the 80s and early 90s, RISC-based systems chewed up the mainframe business from below. In the 90s and early 00s, x86-based systems chewed up the UNIX workstation vendors from below. Only a fool would now ignore the *possibility* that hand-held devices and low-power laptops will now chew up the desktop PC market from below. Intel didn't get where they are today by being fools.