LLVM-MOS – Clang LLVM fork targeting the 6502

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by jjmarr on Sunday November 30, 2025 @03:23PM (#46100049)

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.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by gregsadetsky on Sunday November 30, 2025 @04:30PM (#46100625)

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

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by zozbot234 on Sunday November 30, 2025 @05:08PM (#46100924)

LLVM backends are indeed modular, and the LLVM project does allow for experimental backends. Some of the custom optimization passes introduced by this MOS backend are also of broader interest for the project, especially the automated static allocation for provably non-reentrant functions, which might turn out to be highly applicable to GPU-targeting backends.

It would be interesting to also have a viable backend for the Z80 architecture, which also seems to have a highly interested community of potential maintainers.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by codebje on Sunday November 30, 2025 @06:15PM (#46101443)

https://github.com/jacobly0/llvm-project

... but now three years out of date, because it's hard to maintain :-)

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by codebje on Sunday November 30, 2025 @06:14PM (#46101437)

My experience is that while LLVM is very modular, it also has a pretty high amount of change in the boundaries, both in where they're drawn and in the interfaces between them. Maintaining a fork of LLVM with a new back-end is very hard.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by jjmarr on Sunday November 30, 2025 @06:58PM (#46101772)

I know my company (AMD) maintains an llvm fork for ROCm. YMMV.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by codebje on Sunday November 30, 2025 @08:54PM (#46102587)

I should have qualified: it's hard to do for an individual or very small team as a passion side-project. It's pretty time consuming to keep up with the rate of change in LLVM.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by ahartmetz on Monday December 01, 2025 @05:42AM (#46105834)

Do you know why it's a fork? Als, from this https://github.com/ROCm/llvm-project/commits/amd-staging/ it looks like it might be more appropriately called a staging branch than a fork.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by jjmarr on Monday December 01, 2025 @11:10AM (#46109060)

Various reasons, like embargoes on information, stuff we didn't want to wait for review on before shipping, or features that don't make sense for upstream like `hipcc` which is an `nvcc` wrapper.

Our goal is to get most modifications not in the third category into upstream at some point which makes the maintenance load bearable.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by Sharlin on Sunday November 30, 2025 @03:28PM (#46100091)

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.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by alexrp on Sunday November 30, 2025 @10:43PM (#46103269)

Worth noting that LLVM has AVR and MSP430 backends, so there's no particular resistance to 8-bit/16-bit targets.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by Sharlin on Monday December 01, 2025 @03:05AM (#46104749)

Oh, thanks for the correction. I couldn’t find a conprehensive list of backends (which is weird) and the lists I did find only included 16+ bit targets.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by weinzierl on Sunday November 30, 2025 @05:37PM (#46101133)

These processors were very very different from what we have today.

They usually only had a single general purpose register (plus some helpers). Registers were 8-bit but addresses (pointers) were 16-bit. Memory was highly non-uniform, with (fast) SRAM, DRAM and (slow) ROM all in one single address space. Instructions often involved RAM directly and there were a plethora of complicated addressing modes.

Partly this was because there was no big gap between processing speed and memory access, but this makes it very unlikely that similar architectures will ever come back.

As interesting as experiments like LLVM-MOS are, they would not be a good fit for upstream LLVM.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by zozbot234 on Sunday November 30, 2025 @05:57PM (#46101306)

> ... there was no big gap between processing speed and memory access, but this makes it very unlikely that similar architectures will ever come back. ...

Don't think "memory access" (i.e. RAM), think "accessing generic (addressable) scratchpad storage" as a viable alternative to both low-level cache and a conventional register file. This is not too different from how GPU low-level architectures might be said to work these days.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by djmips on Sunday November 30, 2025 @11:45PM (#46103555)

Great point. And you can even extend that to think like a 6502 or GPU programmer on an AMD, ARM or Intel CPU as well if you want the very best performance. Caches are big enough on modern CPUs that you can almost run portions of your code in the same manner. I bet TPUs at Google also qualify.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by mysterymath on Monday December 01, 2025 @12:43AM (#46103908)

Hey, llvm-mos maintainer here. I actually work on LLVM in my dayjob too, and I don't particularly want llvm-mos upstream. It stretches LLVM's assumptions a lot, which is a good thing in the name of generality, but the way it stretches those assumptions isn't particularly relevant anymore. That is, it's difficult to find modern platforms that break the same assumptions.

Also, maintaining a fork is difficult, but doable. I work on LLVM a ton, so it's pretty easy for it to fold in to my work week-to-week. And quite surprisingly, I used AI to help last time, and it actually helped quite a lot!

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by zozbot234 on Monday December 01, 2025 @03:50AM (#46105057)

Even if y'all don't particularly care about having the full backend upstream just yet, it still seems worthwhile to comprehensively document these assumptions within the project, and perhaps to upstream a few of the simpler custom passes where not too much "stretching" of assumptions is involved, if only to ease future forward-porting work.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by nineteen999 on Monday December 01, 2025 @07:17AM (#46106498)

What's your take on sdcc 6502 support at the moment, if you have one? Im just happy to finally have an 8-bit C compiler that supports both targets, even if the codegen for 6502 needs a lot of work right now.

I'd happily take a llvm-z80 and llvm-6502 over sdcc if both were available

Edit: oh wow, look at that https://github.com/grapereader/llvm-z80. Aw but not touched for 12 years.

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by bbbbbr on Monday December 01, 2025 @04:44PM (#46113696)

Not the parent, but I have a take. :)

For GBDK-2020 we've been using the 6502 support in SDCC to support the NES as a target console for about 2 years alongside the existing Game Boy and SMS/Game Gear targets.

The 6502 port has been usable, but doesn't seem fully mature. There has been a lot of code churn for it during the last 12 months compared to the z80/sm83 ports as it gets improved. Recently (their recommended pre-release build 15614) this seems to have resulted in some breaking regressions that we haven't fully tracked down.

Perhaps this port is getting less testing coverage than the z80/sm83 port. Unsure. The majority of the 6502 work seems to be done by a newer member of their team, with the longer term members seeming to be somewhat hands-off. That might be an additional factor.

Edit: BTW, the 6502 port in SDCC at build 15267 (~4.5.0+) has been reasonably stable and usable, and is what we based our last GBDK-2020 release on (6 months ago).

[ Parent | on HN ]

Re:LLVM-MOS – Clang LLVM fork targeting the 6502 by nineteen999 on Tuesday December 02, 2025 @12:56AM (#46118069)

Ah thank you, that is all very helpful - I've been using 4.4.0 which is fine for Z80 code, but yeah had the feeling 6502 code generation could be improved.

[ Parent | on HN ]