Rust compiles to LLVM IR. I'm pretty surprised that building this transpiler was considered a better use of time than writing an LLVM backend for whatever "weird embedded target" might need this.
In fact there used to be a C backend for LLVM, but it was removed in LLVM 3.1 [0]. JuliaHub has resurrected it as a third-party backend [1], though I have no idea if there is any interest in upstreaming the work from either end.
Sometimes you may need to deal with odd proprietary processors with limited and flawed knowledge about them.
For example, in the 37c3 talk "Breaking "DRM" in Polish trains" by the folks from Dragon Sector (I highly recommend watching it), they needed to reverse-engineer Tricore binaries, however they found the Ghidra implementation had bugs.
As for the PLCs, the IEC 61131-3 functional block diagrams transpile to C code which then compiles to Tricore binaries using an obscure GCC fork. Not saying that anyone would want to write Rust code for PLCs, but this is not uncommon in the world of embedded.
If you write a library in Rust and want to make that library available to other language ecosystems, not requiring a Rust compiler toolchain for using the library is a pretty big plus - instead create a C source distribution of the library, basically using C as the cross-platform intermediate format.
I think you may not be familiar with how embedded development works.
Most teams who write code for embedded devices (especially the weird devices at issue here) don't have the hardware knowledge, time, or contractual ability to write their own compiler backend. They're almost always stuck with the compiler the manufacturer decided to give them.
You're right. But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.
But ya, I believe this project exists for a meaningful purpose, I'm just surprised.
> But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.
They aren't usually building a compiler from scratch; they modify their existing compiler[1] for their new hardware, which is fractions of effort required compared to building a new compiler or modifying the LLVM backend.
Unless it's a completely new ISA, they'll spend an hour or less just adding in the new emit code for only the changes in the ISA.
----------------------------------
[1] Usually just the previous gcc that they used, which is why in 2022 I was working on brand new devices that came with a customised gcc 4.something
I think the approach would not be to alter the manufacturer's compiler directly, but to run your Rust code through a separate Rust-to-C compiler then feed that output into the compiler the manufacturer gave you.
There are many kinds of IRs in compilers - I'm not familiar with how Rust works, but for example GCC has an intermediate representation called GENERIC, which is a C-like language that preserves the scoping and loops and branches of the inputted C code.
Lower level representations also exist - since C has goto, you can pretty much turn any SSA IR to C, but the end result won't be readable.
