I stumbled across this project GitHub - llvm-mos/llvm-mos: Port of LLVM to the MOS 6502 and related processors and I'm curious if it would be possible to build Swift with this llvm and port the embedded standard library to work? There was briefly a rust fork that used this llvm and I thought it could be fun to run Swift code on the NES.
Every time I look into something like this the Swift build script fails to compile even an unmodified toolchain. Did the situation improve since last year? Does it still require hundreds of gigabytes to work?
Not with this LLVM, as it has to be merged upstream first before its changes are propagated downstream to swiftlang/llvm-project fork.
Would you be able to clarify which failure you're referring to? Is there a GitHub issue for this to track?
Also unclear what you're referring to here? I don't think you need hundreds of gigabytes for a release build, especially if you're porting the toolchain alone without the rest of the libraries like Foundation/Dispatch etc.
To clarify what Max said above, it's certainly possible to take the work from the LLVM-MOS project and build Swift on top, but to do it you'd need to merge the patches from LLVM-MOS with the fork of LLVM that Swift uses, and then build Swift with that. I would imagine that won't be entirely trivial.
If you're going to do that, you should understand that Swift periodically rebases its LLVM fork, and every time that happens you would need to re-apply the LLVM-MOS changesets on top, unless they had been merged upstream to the main LLVM repository.
There was another project somewhere that had built an ARM to 6502 transpiler (IIRC) that would let you use the LLVM ARM back-end to generate code and then transpile to 6502, which I think would let you use Swift on 6502 as well. I don't recall where I saw it, mind.
If I still have errors using the build script this time around, I will open an issue
I will try, but if I do run into any significant issues I doubt I will have the time to do anything about them or even just understand all of them.
I want to experiment with old game console hardware using a modern language I like, and I can't really work on any significant changes of my own, at that point the novelty of running Swift code on the platform is probably not worth the effort and I could instead try an existing language
If I do get it to work I definitely will not have the time to maintain it, it's not very practical to begin with. For the curiosity it is, hacking something together once is good enough
After volunteering on a downstream fork of Swift and LLVM for a couple of years, I would not recommend this at all. Maintaining one fork was barely manageable, keeping two forks aligned and buildable could be a full-time job for multiple people. And it doesn't matter if you resolve conflicts once a week, once a month, or once a quarter. Accumulated conflicts make irregular or rare updates even harder.
Whatever effort is put into this project, IMO the most effective approach is to ensure patches reach upstream LLVM. Then assuming MOS backend has test coverage, Swift's LLVM will eventually get it "for free" in a few rebranches when changes propagate downstream.
