That doesn't actually guarantee no funny business, someone could jump into the middle of a multibyte instruction. Generally speaking games shouldn't be doing that so it should be fine, but there's nothing stopping it. It does however show the problem that you can't always actually tell where some code starts within a block.

Note: I'm not talking about the Xbox specially. Its binary format my actually make it clear where every piece of code starts, or there may be other ways of telling.

> That doesn't actually guarantee no funny business, someone could jump into the middle of a multibyte instruction.

Does PowerPC use multibyte instruction that don't have to be aligned? It would be very atypical for RISC processors, but if you can provide evidence that these exist, I will believe you.

(sidenote: I am aware that Thumb and in partiular Thumb-2 on ARM uses instructions of variable 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. You need stronger guarantees then that (Like, for example, that you can't run unaligned instructions, and that all instructions are the same length). 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.

That said, when I wrote that comment I didn't know for sure if the XBox 360 CPU had that or not. Looking it up, it's still not 100% clear to me but I would wager no. 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. 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.

Still, there are some RISCs that have variable length instructions [0], but as you'd expect the majority of them are fixed length (Though, especially in this context RISC vs. CISC can be pretty arbitrary). Even just talking about Game Systems not all of them run RISCs. 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. So it is a problem you have to consider if you're going to be writing a JIT/recompiler/etc. for those architectures.

[0] https://en.wikipedia.org/wiki/Comparison_of_instruction_set_...

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.

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