Statically Recompiling NES Games into Native Executables with LLVM and Go

This is amazing. Also, this is the Dark Magic of programming that I don't think I'll 100% grok in 20 years, but its good to try! edit: now that I think of it, I really need to keep expanding my knowledge. I'm going to go through this post in my terminal and try to at least make the stuff work, so I can start understanding this process. I've been trying to learn Go and C better anyway. Thanks for providing…

I have actually been rather obsessed with this lately. You'll see that there's a few problems he runs into that he deems insurmountable, which sounds like a challenge! Specifically, there's the issue with an instruction which is effectively a computed goto: A jump instruction that takes an address and then jumps to the address STORED at that address. Since there is no way to know at compile time what addresses are going to stored at a place, you're forced to…

All that work, and then he hits the expected killer problem - self modifying code. Getting past that without an interpreter is going to be tough. Not impossible, because the self modifying code isn't that dynamic in the places he found it. It's not like it's reading external input and compiling it. There are a limited number of cases to be handled. It's amusing seeing this in a machine which gets its code from a ROM.

Assembler programmers of that vintage were crazy. I did a fair amount of reverse engineering of Honda engine computers[0] from the late 80's early 90's and this kind of thing was the status quo. These things had 256 _bytes_ of memory, and they used every single one, some of them being multiplexed to do multiple things. There are some interesting, digestible bits in the serial interrupt handler[1] [0]: https://github.com/benogle/obd0vtec_dev/blob/master/src/stoc... [1]…