> Although this is somewhat of the reverse in architectures, going from CISCy to RISCy.
Apple did the same when they moved from 68K to PPC. The PPC would run the 68K code in emulation or, if it was a "fat binary" with both 68K and PPC code, it would just load the functionally equivalent PPC binary and run it.
There were utilities to compress executables that deleted the versions not for the current CPU - very handy in low-power 68Ks
In that case, the PPC had probably a 5-10x perf advantage over the 68k's people were upgrading from. So, it wasn't noticeable, so if in the end the emulated code was only running at the speed of the 68k it was replacing it was a net win every time it entered the kernel and ran native code.
ARM doesn't have this advantage over X86, at best its probably somewhere around 1/2 the absolute performance. Of course intel has been selling a _LOT_ of really slow CPU's down the product line, so for someone upgrading from a atom class machine the ARM will probably appear to be pretty reasonable. Not so much, if your running a fairly high end laptop.
I don't think any ARM emulating x86 code will be able to get to Xeon E7 performance anytime soon. May get close to low-end x86's with JIT and jumping to native mode on every OS call (with some clever adjustment to data structures, if they differ/misalign).
And yes. At that time, PPCs ran rings around x86's and 68K's.
Apple did the same when they moved from 68K to PPC. The PPC would run the 68K code in emulation or, if it was a "fat binary" with both 68K and PPC code, it would just load the functionally equivalent PPC binary and run it.
There were utilities to compress executables that deleted the versions not for the current CPU - very handy in low-power 68Ks