Hacker News new | ask | show | jobs
by kaladin-jasnah 84 days ago
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.

[1] https://github.com/N64Recomp/N64Recomp

2 comments

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.
This vaguely reminds me of futamura projections.

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.

Ah, you are right. I haven't looked at the details of the recomp efforts.