Recompiler: Porting Xbox360 Executables to Windows
github.com
github.com
But the 360's security model specifically out rules self modifying code. And this is enforced by the hypervisor; the system is W xor X, and the transition of a page from W to X has to be accompanied by signatures signed by Microsoft's private key. Nobody, including the kernel, can modify their code.
That might make this one of the first platforms where the static recompilation scheme might make sense in the long term architecture of the emulator.
https://en.wikipedia.org/wiki/Overlay_(programming)
It always seemed like a poor security choice to me, but some game binaries are inexplicably massive and break up easily depending on what phase of the game that you're on.
But on modern consoles (360, PS3 and later) the OS bans games from loading/generating code. To load code they must call out to the OS, which loads it, checks the signatures and puts it in write protected memory.
It's this security mechanism which makes static recompilation viable for 360/PS3 games.
There were rumors that Microsoft would port Windows 10 to the XBox One and then convert XBox games to Windows 10 via the Windows Store, etc. Then you could buy or rent XBox, XBox 360, and XBox One games.
Apple had a Rosetta software that ran PowerMac stuff on Intel Macs until 10.7 removed it IIRC. So Apple has the patents and IP for that.
There was also an old ARDI Executor program that ran old Mac 68K stuff in Windows, Linux, BeOS, etc.
This project doesn't look like it's emulating PowerPC, though. It's tracing the binary, disassembling it, and generating equivalent C++ code. It's a technique called static recompilation.
One of the devs who was working on it has been improving qemus PPC emulation in the meantime though.
Which means all the code on 360 games is clearly marked in the binary and it's impossible for the game to do anything weird like generate or decrypt new code on the fly.
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.
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)
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_...
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.
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'.
You can sorta do this already. Xbox One is running a Windows 10 core and major releases area aligned with windows. You can play significant percentage of Xbox, Xbox 360 and UWP games (like Astroneer for example) on Xbox One.
However, there is an emulator being worked on for the original Xbox called CxBx Reloaded, which is a continuation of the CxBx emulator. To give an idea of how far along it is, here's some recent footage of JSRF:
I'd argue that the fact that the OG Xbox's homebrew scene used the illegally acquired official XDK for the mos part played a part. This meant that they didn't get as deep into documenting the hardware at that early stage, and instead relied on closed source libraries.
I realize x86 != PC as shown by the team that ported Linux to the PS4, another x86 system that has almost no standard PC hardware in it. So I'm sure trying to run XBoxOne binaries on other x86 systems still wouldn't be trivial.
https://github.com/ctm/executor and https://github.com/ctm/syn68k
NES -> native executables: http://andrewkelley.me/post/jamulator.html
x86/Windows starcraft -> arm/Linux for openpandora: https://pyra-handheld.com/boards/threads/starcraft.73844/
(Tools used for this: https://github.com/notaz/ia32rtools)
For a lot of consoles, particularly older ones, this tends to yield worse performance than a JIT. Between different memory layouts, weird threaded code, jump tables, (and especially) self modifying code, a JIT can do a much better job building efficient code since it has all of the runtime information.
For newer consoles which more closely resemble PC hardware, things are definitely better; the current generation will basically look like the Starcraft port; an API compatibility layer.
https://en.m.wikipedia.org/wiki/Profile-guided_optimization
In other words, you create a JIT to run the executable, building a profile of the execution paths at runtime, and use that profile to guide a static decompilation process. That way it should be easier to identify the sections of self-modifying code, as well as model the behaviour of this code.
The only difficulty I can see is how much time it might take to map out all the code paths, but in principal it's possible, and there may be some efficient approaches for doing so.
Asking for a friend...