Quote:
Originally Posted by
theKbStockpiler
Interpreted implies that the Emulator would just be substituting code for other code from a look-up table but then the program would actually be more or less ported at this point would it not?
It's hard to call something 'ported' when it can't run outside the emulator, no.
The exact approach may depend on the emulator in question. qemu, for instance, can use CPU virtualization features if you're emulating the same architecture you're on -- setting up a virtual environment in
hardware. This lets programs run in the virtual environment mostly natively, just trapping a few higher-ring instructions and the like so software can take over and fill in the gaps. This was actually possible without hardware virtualization support, but it makes it much easier and more efficient -- I'm not too well read on the details but suspect it involves more direct/explicit ways for the client to talk to the host, for starters.
For emulators that run instructions that are completely alien to the native processor, the obvious way would be to make a data structure in memory that represents the registers of the native CPU, and use something like a big switch statement or look-up table to branch to the appropriate code for each instruction. If the emulated CPU has fewer registers than the native one I suppose you could stick everything in registers, use jump tables, self-modifying code, raw ASM and other dirty tricks to make it much faster but in the end it's the same idea.