CPU Emulation
Moving in the opposite direction, you get CPU emulation. This is perhaps the best-known form of emulation. The full name of the WINE project, WINE Is Not an Emulator, comes from a desire to distance itself from this kind of emulation, which is typically quite slow.
CPU emulation generally falls into two categories: pure CPU emulation and full system emulation. The latter category is very popular among classic gaming enthusiasts. Emulating an entire system is a complicated undertaking, and doing it quickly is even more difficult. One of the best products for this purpose was Connectix Virtual PC for the Mac. (Note that this was a very different product from Virtual PC for Windows, in spite of the similar names.) This was purchased by Microsoft, which did very little with it.
The x86 instruction set is widely regarded as a convoluted mess. Many instructions have all sorts of side-effects that are sometimes useful, but often completely ignored. Performing most arithmetic instructions, for example, will set several status bits. For a completely accurate emulation, the values of these status bits must be set. This can mean that a single x86 instruction requires a string of Power PC instructions to achieve the same results. One trick that Virtual PC employed was to analyze a sequence of x86 instructions, and not bother computing the values of status bits that were never checked.
In some cases, you don’t need to emulate an entire system. If you want to run an x86 Linux application on Power PC Linux, emulating a CPU, graphics card, hard disk, and so on and then running a second copy of Linux on top of it would be an enormous waste of effort, since you would end up duplicating a lot of running code. A similar situation occurs when running Power PC applications in OS X on an Intel processor, or m68k applications on a Power PC Macintosh.
In this case, the problem is conceptually quite similar to the kind of situation that requires system call translation, but in reverse. The system calls—and even many of the library calls—are the same, but the program calling them cannot run on the native machine. In this case, the solution is a cut-down emulator that only emulates the CPU. Every time the emulated program calls a standard library function or makes a system call, the emulator catches this call and passes it to the native implementation for processing. This setup can provide a significant speed boost; a lot of applications spend a lot of their CPU time inside things like standard GUI libraries, so allowing these to be run natively is a improves speed.
In the Free Software world, the most popular example of this form of emulation is QEMU, which allows Linux binaries compiled for one architecture to be run on another, passing the system calls to the native kernel.