My definition of "emulator" must have been different from yours. Maybe "virtual machine" would have been better. Those emulators do, however, let you run MacOS on non-Apple PPC workstations that have very different system architectures and would never be able to run MacOS natively. The whole machine is emulated, except for the cpu.
Registers would have to exist in ram, and use real cpu registers as a cache, I assume(this is the case in many 68k emulators, see Ardi's paper on syn68k).
I wrote this because I was interested in taking one of the available system emulators/virtual machines(such as MacOnLinux), and adapting it to run with a PPC emulator, instead of running natively. The hardest work seemed to be already finished(reverse-engineering a machine and writing a system emulator is usually much harder than writing a slow cpu emulator from commonly available documentation...optimizing an emulator is a whole other story, though).
My primary focus was to emulate a PPC on an x86. From what I have heard from 68k emulator authors, most of the time is spent generating condition flags, since x86 instructions map well, except for their condition codes. Work is normally done to remove vain generation of condition codes in JIT emulation, although interpreters usually spend most of their time generating them instead of doing something useful. PPC opcodes indicate if flags need to be generated. This already makes PPC emulators run faster than 68k emulators.(although, a 50MHz PPC doesn't run MacOS X very well;-)).
What about other cpu families emulating PPCs? How would a generic VLIW cpu perform? If we needed to take the hardware approach, maybe it would be possible to build a "generic emulator card" that had a very simple(and therefore versatile) VLIW cpu, with a hardware front end(maybe implemented in a software-configurable FPGA) to assist in code translation. Emulation software could then program the front end translator to do most of the interpretation work, and run code on the VLIW cpu to do the remaining work. This wouldn't reach the speeds of running the real CPU on the card, but could speed up emulation of any cpu, and allow software upgradeability when new generations of cpus are released.
Slashdot Mirror
Thanks for the reply...
;-)).
My definition of "emulator" must have been different from yours. Maybe "virtual machine" would have been better. Those emulators do, however, let you run MacOS on non-Apple PPC workstations that have very different system architectures and would never be able to run MacOS natively. The whole machine is emulated, except for the cpu.
Registers would have to exist in ram, and use real cpu registers as a cache, I assume(this is the case in many 68k emulators, see Ardi's paper on syn68k).
I wrote this because I was interested in taking one of the available system emulators/virtual machines(such as MacOnLinux), and adapting it to run with a PPC emulator, instead of running natively. The hardest work seemed to be already finished(reverse-engineering a machine and writing a system emulator is usually much harder than writing a slow cpu emulator from commonly available documentation...optimizing an emulator is a whole other story, though). My primary focus was to emulate a PPC on an x86. From what I have heard from 68k emulator authors, most of the time is spent generating condition flags, since x86 instructions map well, except for their condition codes. Work is normally done to remove vain generation of condition codes in JIT emulation, although interpreters usually spend most of their time generating them instead of doing something useful. PPC opcodes indicate if flags need to be generated. This already makes PPC emulators run faster than 68k emulators.(although, a 50MHz PPC doesn't run MacOS X very well
What about other cpu families emulating PPCs? How would a generic VLIW cpu perform? If we needed to take the hardware approach, maybe it would be possible to build a "generic emulator card" that had a very simple(and therefore versatile) VLIW cpu, with a hardware front end(maybe implemented in a software-configurable FPGA) to assist in code translation. Emulation software could then program the front end translator to do most of the interpretation work, and run code on the VLIW cpu to do the remaining work. This wouldn't reach the speeds of running the real CPU on the card, but could speed up emulation of any cpu, and allow software upgradeability when new generations of cpus are released.