You take an Xbox game designed to run on an Xbox 360, a 64 bit PowerPC system and decompile its binaries back into source code. You now have the ability to modify the game as well as port it to other systems and architectures such as Windows on X86_64 or Linux on ARM64.
It's more nuanced than that; the approach you're describing is usually called "decompilation."
The difference is how far one goes in hoisting the "source code;" in this "recompliation" approach the source code, while C++, is basically an IR (intermediate representation) between the original game's assembly and a host platform, and the hardware itself is emulated (for example, the original architecture's CPU registers are represented as variables in the host architecture's memory). The machine code is translated to C++ using a custom tool.
In a "decompilation" approach the game logic is converted (using a decompiler, like IDA or Ghidra's) back into something which resembles the original source code to the game itself, and the source code is usually hand analyzed, marked up, rewritten, and then ported across platforms. The product is something that attempts to resemble the original game's source code.
Of course, they lie on a continuum and both approaches can be mixed, but, while they both involve C++ in the middle, the process is starkly different. Recompilation is much more copyright-friendly, because in many implementations only the modifications are distributed and the original binary is translated by the end user (who owns the software/a license to it), whereas decompilation produces an artifact (source code) which is a derivative work encumbered by the original software's license and generally should not be distributed.
> In a "decompilation" approach the game logic is converted (using a decompiler, like IDA or Ghidra's) back into something which resembles the original source code to the game itself, and the source code is usually hand analyzed, marked up, rewritten, and then ported across platforms
There definitely is a lot of scope to apply LLMs here
Seeing this [1], I thought it was something related to taking assembly instructions in the original code, emitting C statements that match the instruction, and then compiling that C code.
Your idea is much more accurate; see my sibling comment. It's basically using C or C++ as an intermediate representation for machine code, rather than trying to recreate the game's higher-order logic/structure or source code.
Normally with futamura's first projection the input is source code, and you partial-evaluate that source against an interpreter for that source, resulting in a "compiled" binary that has the logic of the source inlined into the interpreter (and hopefully optimized). This is similar to what Truffle does I believe, where you have an interpreter (written in java) and then during runtime Truffle "JIT" optimizes the interpreted program's AST against the interpreter's logic. All of this can be considered a specialization of the JVM running an interpreter interpreting your program.
In this case with "recompilation" you have a binary made to run on certain hardware. You then take an emulator of the hardware (registers, PC, etc.) and then "partial evaluate" the binary against the hardware emulator, producing a new program that contains a software emulation of just that specific binary.
So while you're still conceptually emulating the underlying hardware, you both avoid the instruction dispatch overhead at runtime (it's statically compiled in) and also benefit from the optimization passes of modern compilers.
