Statically Recompiling NES Games into Native Executables with LLVM and Go
1–10 of 103 posts
Re: Statically Recompiling NES Games into Native Executables with LLVM and Go
#2Re: Statically Recompiling NES Games into Native Executables with LLVM and Go
#3This 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.
Re: Statically Recompiling NES Games into Native Executables with LLVM and Go
#4Re: Statically Recompiling NES Games into Native Executables with LLVM and Go
#5Re: Statically Recompiling NES Games into Native Executables with LLVM and Go
#6This 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.
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... 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.
Re: Statically Recompiling NES Games into Native Executables with LLVM and Go
#8Earlier 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?
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.
Re: Statically Recompiling NES Games into Native Executables with LLVM and Go
#9... 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
#10... 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.
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.