#POWERPC EMULATOR MAC MAC OS#
One reason that this emulation was so successful is that many of the APIs for the Mac OS were originally implemented as traps on the 680x0 processor therefore, calling an API actually was recognised by the 680x0 as the equivalent of an error condition, which would cause it to handle that error through one of its hardware vectors. The 68LC040 had no floating point instructions, making this feat slightly simpler but no less impressive.
#POWERPC EMULATOR MAC CODE#
This emulator was theoretically capable of emulating 680x0 code faster than any real 680x0 was capable of running it. The emulator could recognise the same sequence of 680x0 code and run the previously-cached PowerPC code to avoid doing the translation again.
Dynamic recompilation works by "recompiling" common sections of the code into faster, PowerPC-native, sequences that were locally cached. For the PCI PowerMacs, the dynamic recompilation emulator was used to boost performance.
#POWERPC EMULATOR MAC SERIES#
Early versions emulated it by decoding each instruction and immediately carrying out a series of equivalent PowerPC instructions. Apple developer documents indicate that the emulator provided an operating environment most closely resembling that of the Macintosh Centris 610, a system based on the Motorola 68LC040 microprocessor. Prior to Traut's arrival there, Connectix had released Speed Doubler, which included an even faster PowerPC 68k emulator.Īll versions of this emulator emulated the "user" subset of the 68EC040 instruction set with a 68020/68030 exception stack frame. A later version, using dynamic recompilation, was developed by Eric Traut, who later worked on successful emulation projects at Connectix such as Virtual Game Station and Virtual PC. Sure you have to get things in the right ballpark (stuff like the bugs fixed in Dolphin by not making EXI->MemCard transfers happen instantly), but there's no code saying 'nop for 12 cycles, and expect the system to be in exactly the right state'.The first version was written by Gary Davidian, who had originally created it for use on the Motorola 88000 CPU, used in Apple's abortive first attempt at a RISC target platform. code written against them uses explicit synchronization primitives rather than cycle counting. So, in addition to lack of self modifying code, PS3/360 emulators benefit from hardware that's complex enough that it essentially has to be treated as non-deterministic by the original game developers (within reason). Pretty much every 2600 title relies on this. You've got to do most of that bookkeeping either way to make the effects of the CPU cycle accurate with regards to the rest of the system. The amortization of instruction decode and dispatch represented recompilation (whether static or dynamic) probably doesn't get you much. My gut feeling is you probably wouldn't get great benefits out of that since 2600 code relied on a lot of cycle counting to get anything other than pong out of the graphics hardware. > Though it's my theory that static recompilation might be easier on the Atari 2600, because the limited ram makes it really hard for self modifying code to exist. So it is a problem you have to consider if you're going to be writing a JIT/recompiler/etc. The 6502, z80, and 68k are all classified as CISC and have variable-length instructions sets, and all of those are featured in lots of Game Systems. Even just talking about Game Systems not all of them run RISCs. Still, there are some RISCs that have variable length instructions, but as you'd expect the majority of them are fixed length (Though, especially in this context RISC vs.
Being that clearly people more familiar with the XBox 360 then I am believe compiling the code beforehand is possible, I think it's likely the XBox 360 doesn't have the optional support for variable-length instructions. There are extensions to the PowerPC architecture that have shorter instructions (It appears to be somewhat similar to Thumb), but I was unable to tell whether or not the XBox 360's Xenon supported that. Looking it up, it's still not 100% clear to me but I would wager no. That said, when I wrote that comment I didn't know for sure if the XBox 360 CPU had that or not. You could never really write a recompiler like this for x86 code even though you can mark data with the NX bit, because you can't tell where the instructions start, or whether or not a jump may end-up half-way between an instruction. You need stronger guarantees then that (Like, for example, that you can't run unaligned instructions, and that all instructions are the same length). I wasn't talking specifically about the PowerPC architecture, I was just pointing out that just because a computer supports 'W^X' doesn't mean you can always know exactly what instructions a program will run.
0 kommentar(er)
