Re:Recompiler: Porting Xbox360 Executables to Windows
by monocasa on Thursday October 19, 2017 @02:55PM
(#15510589)
> 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.
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.
The amortization of instruction decode and dispatch represented recompilation (whether static or dynamic) probably doesn't get you much. 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. Pretty much every 2600 title relies on this.
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). ie. code written against them uses explicit synchronization primitives rather than cycle counting. 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'.
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.
The amortization of instruction decode and dispatch represented recompilation (whether static or dynamic) probably doesn't get you much. 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. Pretty much every 2600 title relies on this.
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). ie. code written against them uses explicit synchronization primitives rather than cycle counting. 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'.