Stories with similar links:
- Statically Recompiling NES Games into Native Executables with LLVM and Go via pushcx 10 years ago | 0 points | no comments
- Statically Recompiling NES Games into Native Executables with LLVM and Go - Andrew Kelley via zod000 10 years ago | 9 points | 2 comments
The youtube link is broken because I moved to vimeo when youtube started unconditionally showing ads on all videos. Here’s the vimeo link
edit: never mind, I figured out how to get the embed code for vimeo and updated the article itself to have the new video link.
edit2: this article (and the syntax highlighting, formatting, etc) is the main reason I have been dragging my feet to redo my personal web site. I want to avoid breaking this page. it’s encouraging to see that this is not in vain, and that it is worth preserving. cheers
I remember seeing this article around the time it was published and I think I wrote to you. It’s still one of the most impressive write-ups I have seen.
I was going to mention the BIT trick as a potential pitfall to this type of transpiling attempt, but I see this is addressed in the assembly tricks section. There’s more problems such as self-modifying code, which is a common speedcode technique. Likewise with compressed code.
Another problem is that recompiling things this way will completely destroy any timing-critical code. The NES is particularly temperamental, so you will likely get a rolling screen if you were to run it on real hardware or a good emulator.
On machines where the stack and hardware registers overlap, such as the Atari 2600, these kinds of analyses go out the window. You get things like pointing the stack at hardware registers and doing BRK to get maximum update rate on the screen, just to name one.
x87? :)
Yes, and I think that this is part of why metainterpretation with a JIT is the only practical way to maintain a stable and reasonably well-behaved accelerated emulator.