3 ms·

I can confirm. The PowerPC variant used in the 360 (and PS3) only supports 4 byte instructions and throws an exception if you try to force it to execute instruc

by phire 9y ago

I can confirm. The PowerPC variant used in the 360 (and PS3) only supports 4 byte instructions and throws an exception if you try to force it to execute instructions not 4 byte aligned. Both the PS3 and 360 are in a unique position where they both have strict W^X, OS enforced code signing, and an arch that doesn't let assembly programmers do weird things. This means they are both extremely viable targets for static recompilation. The programmers have zero ablity to do funky business. Also on the PS3 (I'm not sure about the 360) the ABI requires the complier to generate and ship with a list of every single function entry point. Which basically means you are static recompiling with easy mode on. However, you are correct about basically every other console, static recompilation is not easy. (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.

monocasa 9y ago
> 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'.

by phire 9y ago

monocasa 9y ago

> 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'.