FilterHN

LLVM-MOS – Clang LLVM fork targeting the 6502

79 points

by jdmoreira

5 hours ago

| past

| 7 comments

| llvm-mos.org

| HN

▲

HarHarVeryFunny

1 hour ago

[-]

According to this page, LLVM-MOS seems to be pretty soundly beaten in performance of generated code by Oscar64.

https://thred.github.io/c-bench-64/

I think the ideal compiler for 6502, and maybe any of the memory-poor 8-bit systems would be one that supported both native code generation where speed is needed as well as virtual machine code for compactness. Ideally would also support inline assembler.

The LLVM-MOS approach of reserving some of zero page as registers is a good start, but given how valuable zero page is, it would also be useful to be able to designate static/global variables as zero page or not.

▲

zozbot234

4 minutes ago

[-]

AIUI, Oscar64 does not aim to implement a standard C/C++ compiler as LLVM does, so the LLVM-MOS approach is still very much worthwhile. You can help by figuring out which relevant optimizations LLVM-MOS seems to be missing compared to SOTA (compiled or human-written) 6502 code, and filing issues.

▲

gregsadetsky

1 hour ago

[-]

I don't know this world well (I know what llvm is) but - does anyone know why this was made as a fork vs. contributing to llvm? I suppose it's harder to contribute code to the real llvm..?

Thanks

▲

jjmarr

1 hour ago

[-]

LLVM has very high quality standards in my experience. Much higher than I've ever had even at work. It might be a challenge to get this upstreamed.

LLVM is also very modular which makes it easy to maintain forks for a specific backend that don't touch core functionality.

▲

gregsadetsky

36 minutes ago

[-]

Super interesting, thanks. I specifically thought that its modular aspect made it possible to just "load" architectures or parsers as ... "plugins"

But I'm sure it's more complicated than that. :-)

Thanks again

▲

Sharlin

1 hour ago

[-]

Pretty sure that the prospects of successfully pitching the LLVM upstream to include a 6502 (or any 8/16-bit arch) backend are only slightly better than a snowball’s chances in hell.

▲

mtklein

4 hours ago

[-]

This was a nice surprise when learning to code for NES, that I could write pretty much normal C and have it work on the 6502. A lot of tutorials warn you, "prepare for weird code" and this pretty much moots that.

▲

iberator

1 hour ago

[-]

Slightly off-topic. If you want to learn low level assembly programming in the XXI century, 6502 is still an EXCELLENT choice!

Simple architecture and really really joyful to use even for casual programmers born a decade, or two later :)

▲

1000100_1000101

39 minutes ago

[-]

I'd argue that 68K is simpler to learn and use. You get a similar instruction set, but 32-bit registers, many of them. It's even got a relocatable stack so it can handle threading when you get to that point.

▲

chihuahua

19 minutes ago

[-]

I agree, I feel like the 68k architecture was a dream for assembly programming. each register is large enough to store useful values, there are lots of them, there are instructions for multiply and divide. This allows you to focus on the essence of what you want to accomplish, and not have to get side-tracked into how to represent the X-coordinate of some object because it's just over 8 bits wide, or how to multiply to integers. Both of these seemingly trivial things already require thought on the 6502.

▲

self_awareness

3 hours ago

[-]

Rust fork that works on this LLVM fork, for 6502, genering code that can be executed on a Commodore-64: https://github.com/mrk-its/rust-mos

▲

michalpleban

3 hours ago

[-]

How does it compare to cc65 with regard to code size and speed?

▲

asiekierka

2 hours ago

[-]

Here's a benchmark of all modern 6502 C compilers: https://thred.github.io/c-bench-64/ - do note that binary sizes also include the size of the standard libraries, which means it is not a full picture of the code generation density of the compilers themselves.

▲

michalpleban

1 hour ago

[-]

Thank you, that's really helpful.

▲

cmrdporcupine

3 hours ago

[-]

It's been amazing to see the progress on this project over the last 5 years. As someone who poked around looking at the feasibility of this myself, and gave up thinking it'd never be practical, I'm super happy to see how far they've gotten.

Maybe someday the 65816 target will get out there, a challenge in itself.