Statically Recompiling NES Games into Native Executables with LLVM and Go • Hacker News Board

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#101

Post by vidarh » Mon, Jun 10, 2013, 8:20 AM UTC

delroth wrote: post #70

jmhain wrote: post #43

Earlier quoted context omitted.

Why is static pointless and why is dynamic better? If emulating a newer game console, couldn't you get better performance by running a statically recompiled game, since it doesn't have to do the extra work at runtime? Or better yet, couldn't you cross-recompile a game to run it on a platform that couldn't normally handle emulation of the target platform?

You can't: as long as you have self mutating code (including loading more code in memory from another place), static recompiling is simply not possible. It's not a matter of being "better", it's the only solution. As video game consoles start looking more and more like PCs, self mutating code starts to be less frequent and more easily detectable. On the Nintendo 3DS for example, only the OS can allocate executable pa…

That's not really true. A lot of self-modifying code follow very predictable patterns where the modifications treats addresses in parts of the code as a variable. In 6502 code in particular this is a common idiom for looping over arrays of more than 256 bytes. Many of these patterns are easily detectable and easy to statically rewrite.

You likely can't handle the general case, but that's a lot less critical. Especially for old consoles or computers where the pool of software with too complex cases that can't easily be handled with generic analysis is small enough that you can reasonably add special cases for most stuff you care about.

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#102

Post by vidarh » Mon, Jun 10, 2013, 8:26 AM UTC

chadseibert wrote: post #94

derleth wrote: post #89

Earlier quoted context omitted.

The point is historical preservation: Putting ancient games and systems on the Web as a way to enable people to experience them, as part of digital museums, online academic papers, and such, to provide some (imperfect) context for what would otherwise be dry technical history. It's in JS because it's the only language that doesn't require plugins, and so has a better-than-average chance of running on a variety of dif…

But why use a deliberately slow emulator as a base for all of this? Is accuracy really that important when compared to being able to run it on a wide variety of hardware? Why not just bundle some existing JS emulators together or take some fast native emulators and do the emscripten thing?

The two are not competing goals. There are plenty of emulators that aim for speed, so it makes perfect sense for someone to want to focus on accuracy. And yes, it is that important if your goal is to actually preserve things properly.

I don't know about the NES as I never had one, but on the C64 for example, a single cycle deviation in the emulation of interaction between the CPU, graphics chip and memory bus would make some effects impossible to reproduce. And similarly on the C64, people are still struggling to make the SID (sound) chip emulation as accurate as possible, as it used a combination of analogue filters that have proven extremely hard to accurately reproduce in emulation.

People casually testing these games might not care, but many of those of us who used these systems notice these flaws and appreciate that not all of the emulation projects focus only on speed.

Re: Statically Recompiling NES Games into Native Executables with LLVM and Go

#103

Post by acdha » Tue, Jun 11, 2013, 12:55 PM UTC

chadseibert wrote: post #94

derleth wrote: post #89

Earlier quoted context omitted.

The point is historical preservation: Putting ancient games and systems on the Web as a way to enable people to experience them, as part of digital museums, online academic papers, and such, to provide some (imperfect) context for what would otherwise be dry technical history. It's in JS because it's the only language that doesn't require plugins, and so has a better-than-average chance of running on a variety of dif…

But why use a deliberately slow emulator as a base for all of this? Is accuracy really that important when compared to being able to run it on a wide variety of hardware? Why not just bundle some existing JS emulators together or take some fast native emulators and do the emscripten thing?

Because it's fast enough or close to it now and this should only improve over time: it's often much harder to improve accuracy depending on the shortcuts made for performance.