[dleslie]

The toolchains support helps embedded developers, mainly. For example, Xtensa and AVR toolchains are generally byzantine monstrosities of makefiles, Python, dialog, etc; so having them be given a low effort means to consume rust is a boon. Ideally, rust is just another source file in the srcdir soup.

That said, gcc supports more platforms than llvm; including esoteric and unpopular desktop configurations.

Personally, I plan to drop this into marsdev as soon as it releases. Writing 32X games in rust sounds like silly fun.

[steveklabnik]

Incidentally, Xtensa has hired someone for the last… year or so? To make using Rust on their stuff work well.

AVR support is almost there in mainline rustc but has a codegen bug or two, last I heard.

[zRedShift]

I think you meant Espressif, Steve. They have a fork of LLVM with Xtensa support they’re looking to upstream (still a few things missing, like the DSP/AI instructions in ESP32-S3, and I think the codegen is better on GCC for now). And the folks at esp-rs who work at ESP and outside contributors maintain a Rust toolchain and standard library (based on ESP-IDF) which they also want to upstream. There’s also a baremetal target which has a dedicated developer in ESP, it’s pretty amazing. Although esp32-s3 is going to be the last Xtensa chip from them, they’re planning on moving to RISC V, wholesale, with all their products in the last year based on it. Ferrous Systems even designed a Rust specific devkit based on their RISC V esp32-c3, to teach embedded Rust on.

I bet Cadence was ripping them off for the IP, which is a shame…

Any talks in Oxide about porting Hubris to RISC V? I hear getting your hands on Cortex-M*s in bulk is still pretty challenging these days.

[steveklabnik]

Ahh whoops you’re right, lol. Embarrassing.

Hubris was designed to be easy to port to RISC-V, so yes! We didn’t end up doing that though. Someone else did though! https://github.com/oxidecomputer/hubris/discussions/365