rust-mos VS llvm-cbe

For Commodore the computer, there is a Rust and LLVM fork for MOS:

- https://github.com/mrk-its/rust-mos

It's able to generate binaries that are executed on C64. Tried it on the

rust the compiler, hell no.

But there is an llvm-mos project to generate 6502 code and that can be used to cross compile rust code.

https://llvm-mos.org/wiki/Welcome

https://llvm-mos.org/wiki/Rust

https://github.com/mrk-its/rust-mos

It was possible thanks to great https://llvm-mos.org/wiki/Welcome project (it adds 6502 target to LLVM). Adding 6502 support to rust was easy part :] https://github.com/mrk-its/rust-mos

This is a super fun project to play around with. I'm currently trying to build a C64 sprite multiplexer in mostly straight C++ using LLVM-MOS and while it's definitely not going to be the most optimized multiplexer out there, I'm finding it most adequate performance-wise.

Whereas it's probably a long way away from being able to use this for democoding due to the mostly cycle-accurate nature of the effects, for creating homebrew games and utilities this is really quite suitable: write high-level logic and sprinkle in some inline assembly here and there for the really performance critical parts.

The code that is being generated is already quite good and (on first glance) looks better than what's coming out of cc65, for instance.

There's also rust-mos which uses LLVM-MOS to compile Rust code. It unfortunately still has some issues (e.g. [1]) but that is looking really promising as well.

Kudos to all involved :)

[1] https://github.com/mrk-its/rust-mos/issues/16

The MEGA 65 doesn't appear to have shipped yet. The best data I could find is the MEGA 65 is based on a "GS4510". The "GS4510" is compatible with a "4502", which in turn is compatible with the 65CE02. The 65CE02 uses a different manufacturing process but the same ISA as the 6502, which is supported by rust-mos and lvm-mos](https://github.com/llvm-mos/llvm-mos).

Using llvm-mos, rust-mos, a lot of time compiling compilers and support from Mariusz (the rust-mos author), I was finally able to program like it was 1982...

This fork is handy for that. It’s fun to play with, but you need to do a decent amount yourself to get it set up.

https://github.com/mrk-its/rust-mos

Thanks to llvm-mos project there is also working rust fork for MOS-6502: https://github.com/mrk-its/rust-mos/tree/mos_target, so you can target 8-bit atari and c64

So how does the LLVM C backend work then?

https://github.com/JuliaHubOSS/llvm-cbe

One alternative worth mentioning, though, would be the LLVM C Backend maintained by the Julia community.

If you drop "easily" and "human" (/s) from your requirements list, then the C backend for LLVM might work. Then you can choose any programming language you want that has LLVM 10-compatible frontend.

If you really must have something that compiles in C (e.g. for a platform where you only have a C compiler) there's an LLVM backend that outputs C code: https://github.com/JuliaComputingOSS/llvm-cbe

You can convert llvm bitcode to C and then use C compiler, there is such project https://github.com/JuliaComputingOSS/llvm-cbe .

I'm really surprised that the LLVM C backends have continually been resurrected then abandoned over the years. It's a good solution to this sort of thing and would enable a lot of cool stuff like Rust to weird embedded platforms. The most recent one is the Julia backend: https://github.com/JuliaComputingOSS/llvm-cbe

Check this project out: https://github.com/JuliaComputingOSS/llvm-cbe.

Well IMO it can definitely be rewritten in Julia, and to an easier degree than python since Julia allows hooking into the compiler pipeline at many areas of the stack. It's lispy an built from the ground up for codegen, with libraries like (https://github.com/JuliaSymbolics/Metatheory.jl) that provide high level pattern matching with e-graphs. The question is whether it's worth your time to learn Julia to do so.

You could also do it at the LLVM level: https://github.com/JuliaComputingOSS/llvm-cbe

For interesting takes on that, you can see https://github.com/JuliaLinearAlgebra/Octavian.jl which relies on loopvectorization.jl to do transforms on Julia AST beyond what LLVM does. Because of that, Octavian.jl beats openblas on many linalg benchmarks

You can try your luck with the "resurrected" C backend: https://github.com/JuliaComputingOSS/llvm-cbe

I don't understand why I see so many requests for LLVM-based languages to change around their backend or IR, that seems to be a huge amount of work for comparatively little benefit. The correct thing to do there is to just add support for those to LLVM.