Live data from Hacker News

Statically Recompiling NES Games into Native Executables with LLVM and Go

andrewkelley.me

1–10 of 103 posts

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

#3
post #2

This is one excellent read! Thanks to the author for writing this down. Not that i'm not interested in the NSA, but this is a welcome diversion. And something I wanted to play with myself for a long time.

Thank you. I do not write often, so this was a challenge for me. Constructive criticism welcome.

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

#6
post #2

This is one excellent read! Thanks to the author for writing this down. Not that i'm not interested in the NSA, but this is a welcome diversion. And something I wanted to play with myself for a long time.

Thank you. I do not write often, so this was a challenge for me. Constructive criticism welcome.

Well you certainly rose to the occasion. I look forward to leisurely reading this in detail.

Before I looked at the article I immediately wondered how you were going to handle self-modifying code (running on the internal RAM of course). I guess you didn't encounter that situation?

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

#7
post #4

... while it's not really useful for the NES, which is so old that emulating it does not strain even the crudest modern processor, I'd be excited to see this technique applied to newer consoles for lightweight mobile processors.

Emulating accurately takes much more power than you'd think: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-o...;

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

#8
post #6

Earlier quoted context omitted.

Thank you. I do not write often, so this was a challenge for me. Constructive criticism welcome.

Well you certainly rose to the occasion. I look forward to leisurely reading this in detail. Before I looked at the article I immediately wondered how you were going to handle self-modifying code (running on the internal RAM of course). I guess you didn't encounter that situation?

That situation is covered in this section: http://andrewkelley.me/post/jamulator.html#dirty-assembly-tr...

Basically I embed an interpreter runtime and use it only when necessary, such as in the case when the program jumps to RAM.

Good point though. I should specifically mention self-modifying code.

Note that with NES games, self modifying code is uncommon, because programs are 32 KB ROM, and you only have 2KB RAM. So you'd have to first copy your subroutine from ROM to RAM, and then jump to it. And then you have that much less RAM to work with.

However, some of the emulator test ROMs[1] people have made use this technique to test every instruction.

[1]: http://wiki.nesdev.com/w/index.php/Emulator_tests

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

#9
post #4

... while it's not really useful for the NES, which is so old that emulating it does not strain even the crudest modern processor, I'd be excited to see this technique applied to newer consoles for lightweight mobile processors.

Emulating accurately takes much more power than you'd think: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-o... ;

Oh, I know, but that's usually really tiny edge-case things. NES emulation was "good-enough" speed and accuracy-wise a decade ago. These days even an older-model smartphone can emulate NES games solidly well.

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

#10
post #4

... while it's not really useful for the NES, which is so old that emulating it does not strain even the crudest modern processor, I'd be excited to see this technique applied to newer consoles for lightweight mobile processors.

I hinted at the end what kind of technique I think might actually be useful:

  For example, one such technique is to identify a section of code, make some
  assumptions based on heuristics which allow for highly optimized native code
  generation, and then detect if those assumptions are broken. If the assumptions
  are broken, the generated native code is tossed, and emulation takes over.
  However, if the assumptions are upheld, the recompiled block of code will
  execute with blazing fast native speed.
Post reply on HN