Static recompilation - Is it possible?

[pikachuchujelly]

I know this topic has come up quite a few times, but I want to know if such a thing is possible to any degree, even if it's not perfect, to precompile the code beforehand instead of JIT compiling. Now, I'm not a programmer, but I know that JIT is used almost all the time, because it always produces more reliable results than static recompiling, and more accurately simulates the operating environment.

I've always used 1964 for n64 emulation on my old EeePC laptop that has a Celeron M 353 @ 900 MHz. (In other words, complete and utter crap specs). Super Mario 64 ran at full speed most of the time, but lagged on a few spots and sound was kinda choppy. Then I tried Corn, which is a very old n64 emulator that uses static compiling. It was able to emulate at more than 5x the speed of 1964. Corn can only run a few N64 games (48 total, I think), but it's emulation speed is over the top because of the use of static compiling.

So, I want to know if it's even remotely possible to use static compiling to enhance the speed of games at the cost of emulation accuracy. What about combining the two and using dynamic compilation and some game-specific hacks to patch the precompiled code? If it's completely impossible, what makes Gamecube emulation different from Nintendo 64 emulation, besides the CPU architecture?

[pauldacheez]

I doubt Corn actually really used any sort of static recompilation. It was just really fuckin' fast for some other reason.

Static recompilation is pretty much impossible for any console emulator – any CPU-specific optimizations or assembly hax would have to be thoroughly worked around, and at some point it becomes so difficult and unmaintainable that a JIT recompiler is simpler and easier to speed up.

If you don't believe me, there was a guy who tried to do this with NES games. He ended up having to put an interpreter into the thing to fix all the bugs. http://andrewkelley.me/post/jamulator.html