How one processor convincingly pretends to be a different one

There is a settled way of talking about emulation. It is worth asking how much of it survives contact with the detail.

The naive approach is a loop

The simplest emulator reads one instruction of the guest program, works out what it means and performs the equivalent action. Doing that faithfully requires modelling registers, flags and memory exactly as the original processor would have arranged them.

Every guest instruction costs many host instructions, so this approach runs an order of magnitude slower than the original hardware. It is nonetheless valuable, because it is straightforward to verify and easy to inspect while debugging. Emulators for very old machines often use it happily, since modern hardware is fast enough for the deficit not to matter.

Translating once and reusing the result

Faster emulators identify a run of guest instructions and translate the whole block into equivalent host instructions in one pass. The translated block is stored, so the next time execution reaches that address the host code runs directly without translation.

Because programs spend most of their time in loops, the translation cost is paid once and amortised over many executions. The translator can also optimise, discarding flag calculations that nothing subsequently reads and combining redundant operations. This is why a well-built emulator can approach a substantial fraction of native speed on ordinary application code.

What makes emulation genuinely hard

Instruction behaviour is documented, but real programs frequently depend on behaviour that was never documented at all. Older systems were often programmed against precise timing, so a faithful emulator must reproduce how long things took. Self-modifying code invalidates translated blocks, which forces the emulator to detect writes to code it has already translated.

Hardware quirks in video and sound chips are what give a system its character, and reproducing them takes far more work than the processor. This is why emulator accuracy improves for decades after a system is obsolete, as edge cases are discovered and reproduced.

Emulation, virtualisation and translation layers

Virtualisation runs guest code natively on the same architecture, with the hardware isolating it, so there is no translation at all. That is why a virtual machine of the same architecture is fast while emulating a different architecture is inherently expensive. A compatibility layer translates system calls rather than instructions, letting programs built for one operating system run on another.

Mechanically, such a layer is not an emulator, since the processor instructions execute directly and only the interface is being reinterpreted.

Many real systems combine all three, which is why the boundaries are blurred in everyday conversation about them.

Why architecture transitions now feel smooth

When a platform changes processor architecture, the vendor ships a translator so existing software continues to run. Translation happens at installation or on first run, and the result is stored so subsequent launches skip the work entirely. Hardware support helps enormously, particularly instructions that reproduce the memory ordering rules of the architecture being emulated.

Under load, memory ordering is a subtle source of bugs, because code written for a stricter model breaks quietly on a looser one. Without that hardware assistance, the emulator must insert expensive barriers everywhere, which costs a great deal of performance.

Firmware updates change this behaviour more often than hardware does.

Emulation as the only path to preservation

Original hardware decays, with capacitors, drives and displays failing in ways that eventually become unrepairable. Software written for a machine cannot outlive that machine unless something can reproduce the environment it expects.

Emulators are therefore the practical mechanism by which decades of software remain runnable rather than merely archived. Accuracy matters more here than speed, because a preserved program should behave as it did rather than as fast as possible. Legal access to the original software and firmware remains the harder obstacle, and it varies considerably by jurisdiction.

The takeaway

The trick is not translating instructions; it is remembering the translation.

The constraint is almost always physical, and marketing rarely mentions which one.