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.