Show HN: Programming language for making NES games

Re:Show HN: Programming language for making NES games by leroy-is-here on Tuesday March 07, 2023 @03:13PM (#35060537)

I didn’t take a deep dive, but I’m interested in how you keep the binary size small. Is it simply that LLVM, etc., all have too much function overhead and don’t take advantage of routines over subroutines (function calls)? Or is your back-end just specialized enough to take advantage of architecture-specific features the larger compiler suites don’t have the time to care about?

Anyway, this looks dope. Truthfully, we could use more hyper-specific languages like this in all sorts of areas.

[ Parent | on HN ]

Re:Show HN: Programming language for making NES games by pubby on Tuesday March 07, 2023 @03:33PM (#35060805)

LLVM and GCC are great at optimizing until the last leg of the race where they convert IR to assembly code. Their back-ends were designed for modern systems, not the ancient 6502, and so getting them to work involves kludges and clever hacks. I recall there being a video on how LLVM approaches this - search LLVM MOS on youtube.

I plan on writing an article on how my own code generator works. If you check my HN profile in a week or two you'll probably see it submitted.

[ Parent | on HN ]

Re:Show HN: Programming language for making NES games by leroy-is-here on Tuesday March 07, 2023 @05:43PM (#35062363)

Good work. I’m looking forward to the article.

[ Parent | on HN ]

Re:Show HN: Programming language for making NES games by mysterymath on Tuesday March 07, 2023 @06:48PM (#35063100)

In LLVM-MOS, we mainly struggle with its register allocator; the rest of the backend is really quite reasonable.

The "Greedy register allocator" in LLVM is a just finely tuned priority allocator with nice live-range splitting. It works great for zero page cache locations, but it's just not tuned very well for tight register classes like those involving the processor's three architectural registers. I've half a mind to implement Hack's SSA-based register allocator in LLVM to use on A, X, and Y; this would clean up the oodles of spurious copies LLVM-MOS spits out in the worst cases.

[ Parent | on HN ]