Discover

An 'emulator' duplicates (provides an 'emulation' of) the functions of one system with a different system, so that the second system behaves like (and appears to be) the first system. This focus on exact reproduction of external behavior is in contrast to simulation, which concerns an abstract model of the system being simulated, often considering internal state.

Contents

Emulators in computer science

Structure

Memory subsystem

CPU simulator

I/O

Legal controversy

See also

References

External links

Emulators in computer science

'Emulation' refers to the ability of a program or device to 'imitate' another program or device. Many printers, for example, are designed to emulate Hewlett-Packard LaserJet printers because so much software is written for HP printers. By emulating an HP printer, a printer can work with any software written for a real HP printer. Emulation "tricks" the software into believing that a device is really some other device.
A 'hardware emulator' is an emulator which takes the form of a hardware device. Examples include printer emulators inside the ROM of the printer, and FPGA-based hardware emulators.
In a theoretical sense, the Church-Turing thesis implies that any operating environment can be emulated within any other. In practice, it can be quite difficult, particularly when the exact behavior of the system to be emulated is not documented and has to be deduced through reverse engineering. It also says nothing about timing constraints; if the emulator does not perform as quickly as the original hardware, the emulated software may run much more slowly than it would have on the original hardware.

Structure

Most emulators just emulate a hardware architecture — if operating system firmware or software is required for the desired software, it must be provided as well (and may itself be emulated). Both the OS and the software will then be interpreted by the emulator, rather than being run by native hardware. Apart from this interpreter for the emulated machine's language, some other hardware (such as input or output devices) must be provided in virtual form as well; for example, if writing to a specific memory location should influence the screen this would need to be emulated.
While emulation could, if taken to the extreme, go down to the atomic level, basing its output on a simulation of the actual circuitry from a virtual power source, this would be a highly unusual solution. Emulators typically stop at a simulation of the documented hardware specifications and digital logic. Sufficient emulation of some hardware platforms requires extreme accuracy, down to the level of individual clock cycles, undocumented features, unpredictable analog elements, and implementation bugs. This is particularly the case with classic home computers such as the Commodore 64, whose software often depends on highly sophisticated low-level programming tricks invented by game programmers and the demoscene.
In contrast, some other platforms have had very little use of direct hardware addressing. In these cases, a simple compatibility layer may suffice. This translates system calls for the emulated system into system calls for the host system.
Developers of software for embedded systems or video game consoles often design their software on especially accurate emulators called simulators before trying it on the real hardware. This is so that software can be produced and tested before the final hardware exists in large quantities, so that it can be tested without taking the time to copy the program to be debugged at a low level without introducing the side effects of a debugger. In many cases, the simulator is actually produced by the company providing the hardware, which theoretically increases its accuracy.
Typically, an emulator is divided into modules that correspond roughly to the emulated computer's subsystems.
Most often, an emulator will be composed of the following modules:

★ a CPU emulator or CPU simulator (the two terms are mostly interchangeable in this case)

★ a memory subsystem module

★ various I/O devices emulators
Buses are often not emulated, either for reasons of performance or simplicity, and virtual peripherals communicate directly with the CPU or the memory subsystem.

Memory subsystem

It is possible for the memory subsystem emulation to be reduced to simply an array of elements each sized like an emulated word; however, this model falls very quickly as soon as any location in the computer's logical memory does not match physical memory.
This clearly is the case whenever the emulated hardware allows for advanced memory
management (in which case, the MMU logic can be embedded in the memory emulator, made a module of its own, or sometimes integrated into the CPU simulator).
Even if the emulated computer does not feature an MMU, though, there are usually other factors that break the equivalence between logical and physical memory: many (if not most) architecture offer memory-mapped I/O; even those that do not almost invariably have a block of logical memory mapped to ROM, which means that the memory-array module must be discarded if the read-only nature of ROM is to be emulated. Features such as bank switching or segmentation may also complicate memory emulation.
As a result, most emulators implement at least two procedures for writing to and reading from logical memory, and it is these procedures' duty to map every access to the correct location of the correct object.
On a base-limit addressing system where memory from address ''0'' to address ''ROMSIZE'' is read-only memory, while the rest is RAM, something along the line of the following procedures would be typical:

void WriteMemory(word Address, word Value) {
word RealAddress;
RealAddress=Address+BaseRegister;
if(RealAddress if(RealAddress>ROMSIZE) Memory[RealAddress]=Value;
} else {
RaiseInterrupt(INT_SEGFAULT);
}
}


word ReadMemory(word Address) {
word RealAddress;
RealAddress=Address+BaseRegister;
if(RealAddress return Memory[RealAddress];
} else {
RaiseInterrupt(INT_SEGFAULT);
return NULL;
}
}


CPU simulator

The CPU simulator is often the most complicated part of an emulator. Many emulators are written using "pre-packaged" CPU simulators, in order to concentrate on good and efficient emulation of a specific machine.
The simplest form of a CPU simulator is an interpreter, which follows the execution flow of the emulated program code and, for every machine code instruction encountered, executes operations on the host processor that are semantically equivalent to the original instructions.
This is made possible by assigning a variable to each register and flag of the simulated CPU. The logic of the simulated CPU can then more or less be directly translated into software algorithms, creating a software re-implementation that basically mirrors the original hardware implementation.
The following example illustrates how CPU simulation can be accomplished by an interpreter. In this case, interrupts are checked-for before every instruction executed, though this behavior is rare in real emulators for performance reasons.
void Execute(void) {
if(Interrupt!=INT_NONE) {
SuperUser=TRUE;
WriteMemory(++StackPointer, ProgramCounter);
ProgramCounter=InterruptPointer;
}
switch(ReadMemory(ProgramCounter++)) {
/
★

★ Handling of every valid instruction

★ goes here...

★ /
default:
Interrupt=INT_ILLEGAL;
}
}
Interpreters are very popular as computer simulators, as they are much simpler to implement than more time-efficient alternative solutions, and their speed is more than adequate for emulating computers of more than roughly a decade ago on modern machines.
However, the speed penalty inherent in interpretation can be a problem when emulating computers whose processor speed is on the same order of magnitude as the host machine. Until not many years ago, emulation in such situations was considered completely impractical by many.
What allowed breaking through this restriction were the advances in dynamic recompilation techniques. Simple ''a priori'' translation of emulated program code into code runnable on the host architecture is usually impossible because of several reasons:

★ code may be modified while in RAM, even if it is modified only by the emulated operating system when loading the code (for example from disk)

★ there may not be a way to reliably distinguish data (which should not be translated) from executable code.
Various forms of dynamic recompilation, including the popular Just In Time compiler (JIT) technique, try to circumvent these problems by waiting until the processor control flow jumps into a location containing untranslated code, and only then ("just in time") translates a block of the code into host code that can be executed.
The translated code is kept in a ''code cache'', and the original code is not lost or affected; this way, even data segments can be (meaninglessly) translated by the recompiler, resulting in no more than a waste of translation time.
CPU emulators are popular among some gamers. Some computer games are designed for slower computers and will not work properly on newer, faster computers. Some CPU emulators, such as Mo'Slo, can slow down the CPU, or a process of a program, allowing it to work properly.
Some older games were not designed with the speed of faster computers in mind. A game designed for a 30 MHz PC with a level timer of 300 game seconds might only give the player 30 seconds on a 300 MHz PC. Other programs, such as DOS programs, may not even run on faster computers.

I/O

Most emulators do not, as mentioned earlier, emulate the main system bus; each I/O device is thus often treated as a special case, and no consistent interface for virtual peripherals is provided.
This can result in a performance advantage, since each I/O module can be tailored to the characteristics of the emulated device; designs based on a standard, unified I/O API can however rival such simpler models, if well thought-out, and they have the additional advantage of "automatically" providing a plug-in service through which third-party virtual devices can be used within the emulator.
A unified I/O API may not necessarily mirror the structure of the real hardware bus: bus design is limited by several electric constraints and a need for hardware concurrency management that can mostly be ignored in a software implementation.
Even in emulators that treat each device as a special case, there is usually a common basic infrastructure for:

★ managing interrupts, by means of a procedure that sets flags readable by the CPU simulator whenever an interrupt is raised, allowing the virtual CPU to "poll for (virtual) interrupts"

★ writing to and reading from physical memory, by means of two procedures similar to the ones dealing with logical memory (although, contrary to the latter, the former ''can'' often be left out, and direct references to the memory array be employed instead)

Legal controversy

:''See article Console emulator — Legal issues''

See also

★ Simulation

★ List of emulators — Software emulators:

★
★ Arcade emulator

★
★ Console emulator

★ Other uses of the term emulator in the field of computer science:

★
★ Server emulator

★
★ Terminal emulator

★
★ Game engine recreation

★ Hardware emulators:

★
★ Field Programmable Gate Array (FPGA) Arcade hardware emulators.

★
★ Field Programmable Gate Array (FPGA) CPU hardware emulators.

★ Translation:

★
★ Binary translation

★ In-circuit emulator (ICE)

★ Virtual machine

★ Virtual console

★ Source port

References

External links

★ ''HowTo: Writing a Computer Emulator''

★ WABI - Application Programming Interface (API) Translator from Sun Microsystem

★ Checklist — Emulator Compatibility lists

★ ''The History of Emulation — 1800 to 1999:'' Part 1, Part 2, Part 3, Part 4

★ EmuFAQ — collection of essays surrounding the legality of emulators

★ A Simple Python CPU Emulator Implementation

★ Emulator News — Free Online Games — and Emulator downloads

★ Mo'Slo — a popular CPU emulator with slow-down capabilities

★ The Oldskool PC — provides information on how to run older games on newer computers

★ EPROM emulator - hardware EPROM emulator for fast, easy program development