rust-mos VS embassy

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

Embassy got _some_ support for rp2350 for quite some time now

https://github.com/embassy-rs/embassy

TL;DR: No. Maybe? Depends.

It's probably reasonable to make a distinction between "Real Time" desktop/server OS (on CPUs) vs "Real Time" embedded hardware OS (on MCUs).

(Even aside from any hard-/soft- real time distinction.)

On the embedded side, in addition to FreeRTOS (upon which Pebble OS is built), I'm aware of others with reasonably high profile such as:

* Zephyr (Linux Foundation, C): https://en.wikipedia.org/wiki/Zephyr_(operating_system)

* NuttX (Apache Software Foundation, C & C++): https://en.wikipedia.org/wiki/NuttX

In addition, there's also some "up & coming" Rust language projects which fall somewhere along the "framework" to "OS" spectrum (in part, via https://arewertosyet.com):

* Tock: https://github.com/tock/tock

* Embassy: https://github.com/embassy-rs/embassy

* Hubris: https://hubris.oxide.computer

On the desktop side, I seem to recall in the past, OS such as BeOS & QNX have been presented as a possible future for real time desktop OS that hasn't arrived.

As someone else already mentioned, PREEMPT_RT being merged for Linux is a recent development somewhat in this space which could have impact on both desktop & "embedded" situations but suitability varies dependent on, say, whether you're wanting to use it for audio production versus controlling some 10 tonne robot operating next to humans.

Hope this at least goes some way to answering your question. :)

The other comment implied it but I think it's worth pointing out that:

> embedded applications that can't have asynchronous execution

Is most definitely not the case.

They can't have the same type of async runtime that would be optimal for a web server or the likes (and I'm not sure all desktop applications and web servers are going to always benefit from the same runtime in the same way), but that's a point in favour of Rust's model imho

If you're interested this is an embedded async runtime that's expected to run in no-std and no-alloc environments

https://embassy.dev/

In this article, I will guide you through creating a Snake game in embedded Rust on the BBC Micro:bit using the asynchronous framework Embassy.

Rust solved this by autogenning code from mfgr published device xml descriptors. Eg https://embassy.dev/

Better than any C(++) embedded hal I've used