alt Hacker NewsRust 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.
Replies
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.
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.
I have never seen any guides or blogs about writing LLVM backend
and considering how long compiling LLVM takes... it's reasonable to go for other options
This would cover many different weird embedded targets, and a lot of those targets can be an utter pain to target with a compiler.
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.
[0]: https://releases.llvm.org/3.1/docs/ReleaseNotes.html
[1]: https://releases.llvm.org/3.1/docs/ReleaseNotes.html