3 ms·

While this is very impressive there is an important qualifier missing from the article. They are NOT comparing the output from the same programming languages a

by throw2030401 2y ago

While this is very impressive there is an important qualifier missing from the article. They are NOT comparing the output from the same programming languages and so probably not the same source code either. - Their compiler uses a custom language (NesFAB) and does NOT support C - The reference compilers are all using C "NESFab is a new programming language for creating NES games. Designed with 8-bit limitations in mind, the language is more ergonomic to use than C, while also producing faster assembly code." And http://pubby.games/nesfab/doc.html#_what_is_nesfab http://pubby.games/nesfab/doc.html#_what_is_nesfab Presumably they made a best effort to implement their algorithm as closely as possible in the two languages, but that's a lot different than comparing the output of compilers using identical input source code. So instead of saying - "In a bizarre twist, my compiler generates faster code than GCC, LLVM, and every other compiler I compared it to." It would be more accurate to say - " In a bizarre twist, my compiler [and language] generate faster code than GCC, LLVM, and every other compiler I compared it to [using C].

Joker_vD 2y ago
Eh. The article uses extern char fn(void); char kekw(void) { const char foo = fn() ^ 5; return foo - (foo & 3); } as a running example, and while godbolt only has cc6502, that thing indeed generates worse code, with helper subroutine calls and doing some strange stack juggling.
- throw2030401 2y ago
  It is clearly not what their charts are based on though. Their example output jsr fn eor #5 ldx #3 sax S sec sbc S rts Is better but not drastically so than the output of another 6502 compiler on godbolt: _kekw_sloc0_1_0: .ds 1 _kekw: jsr _fn eor #0x05 tax and #0x03 sta *_kekw_sloc0_1_0 txa sec sbc *_kekw_sloc0_1_0 rts
  - throw2030401 2y ago
    However the output of llvm-mos on godbolt is garbage
djmips 2y ago
I tend to agree with your sentiment since there are a number of other 6502 compilers available to compare with - I'm most familiar with KickC for example. A decent recent summary here showing a lot of various approaches over the years (doesn't include NesFAB though) https://8bitworkshop.com/blog/compilers/higher-level-6502-programming.md.html https://8bitworkshop.com/blog/compilers/higher-level-6502-pr... A possibly interesting comparision of KickC vs CC65 vs VBCC vs 6502-gcc https://sgadrat.itch.io/super-tilt-bro/devlog/219534/benchmark-c-compilers-for-the-6502-cpu https://sgadrat.itch.io/super-tilt-bro/devlog/219534/benchma...

Joker_vD 2y ago

Eh. The article uses extern char fn(void); char kekw(void) { const char foo = fn() ^ 5; return foo - (foo & 3); } as a running example, and while godbolt only has cc6502, that thing indeed generates worse code, with helper subroutine calls and doing some strange stack juggling.

throw2030401 2y ago
It is clearly not what their charts are based on though. Their example output jsr fn eor #5 ldx #3 sax S sec sbc S rts Is better but not drastically so than the output of another 6502 compiler on godbolt: _kekw_sloc0_1_0: .ds 1 _kekw: jsr _fn eor #0x05 tax and #0x03 sta *_kekw_sloc0_1_0 txa sec sbc *_kekw_sloc0_1_0 rts
- throw2030401 2y ago
  However the output of llvm-mos on godbolt is garbage

djmips 2y ago

I tend to agree with your sentiment since there are a number of other 6502 compilers available to compare with - I'm most familiar with KickC for example. A decent recent summary here showing a lot of various approaches over the years (doesn't include NesFAB though) https://8bitworkshop.com/blog/compilers/higher-level-6502-programming.md.html https://8bitworkshop.com/blog/compilers/higher-level-6502-pr... A possibly interesting comparision of KickC vs CC65 vs VBCC vs 6502-gcc https://sgadrat.itch.io/super-tilt-bro/devlog/219534/benchmark-c-compilers-for-the-6502-cpu https://sgadrat.itch.io/super-tilt-bro/devlog/219534/benchma...