The term you want[1] is
binary translation. While static translations are certainly possible - as shown by the ARM translation of
Starcraft, among other things - the use of
dynamic binary translation, while less efficient, is far more common, being basically the same process used in JIT 'compilers' to translate bytecodes, which are the foundational methods used in both Java and .Net.
It has been used for emulators going back to at least the 1980s, and was used by the PowerPC Macintoshen to run M68K code, and later x86 Macs to run PPC code. Most modern cross-architecture emulators (e.g., QEMU) perform binary translations rather than instruction-per-instruction interpretation; as with any JIT translation, it slows down the loading process but drastically reduces the total emulation overhead. It is usually done piecemeal rather that translating a whole system or program at once, with the translated code being cached/memoized to reduce repeated translations but with the LRU code being discarded if memory is needed, which if the caching isn't tuned well can lead to re-translations.
This approach also makes it easy to handle trapping system calls and such in a consistent manner - rather than having separate methods for virtualizing native code versus emulating non-native code, they simply convert the non-native code to native and virtualize it the same way.
Hardware dynamic binary translation is fairly common as well, and has largely displaced microcode as the means for managing complex instructions. While the original
Transmeta Crusoe chip[2] was a failure, the technique has found its way into all of the later Intel x86 CPUs as part of it instruction decoding.
Aside from the advantage of being able to batch translate instructions (just as with emulators), it also means that the CPU can manipulate and optimize the micro-operations, rather than just the x86 code. One of the things often missed in discussions about register renaming, out of order instruction processing, etc. is that the CPU isn't doing that with the x86 registers and instructions, but with the micro-instructions and a huge anonymous register file with (IIUC) up to 1024 registers.
Internally, a modern i7 has more in common with a UltraSPARC than an 8088. Their advantage over (other) RISC designs is entirely in the extremely late binding of the optimizations - it is, in effect, using Massalin's code synthesis approach at the hardware level. In principle, these techniques could be applied just as easily to a hardware implementation of JVM or .Net, or even bypass bytecode entirely and implement a hardware translation of a high-level language a la the Burroughs mainframes and the LispMs - but since what users[3] actually want is not to have to change anything, they use it to keep a long-dead[4] design going in emulation decade after decade, and will probably continue to do so long after everyone on the forum is to dust.
- Which I knew existed but couldn't recall - I managed to find it by looking up Transmeta on Wikipedia.
- Where it was called "Code Morphing Software™" - same thing, just with a trademarked name.
- On both the consumer and commercial levels. Consumers don't want to have to learn anything new, while businesses don't want to pay for anything new. If anything commercial users are even more conservative than home users - the biggest would just as soon still be using Big Iron if they could, despite the fact that just running the mainframes was ruinously expensive, and few want to spend money even if it means saving money later. Anyone who thinks business decisions are rational or profit-focused hasn't actually observed business decisions being made.
- This isn't hyperbole. The x86 as an architecture hasn't actually existed since the 1990s, any more than the System/360 has - we may be running x86 software, but it isn't on x86 hardware, no matter what Intel and AMD claim. Admittedly, this could be seen as nitpicking, and one could even say that by this standard that, since the older x86 systems used microcode, there never was such a thing as x86 in hardware, so make of this what you will.