4 ms·
Impediments to transpiling Rust to C?
- rurban 8y agoNobody in C land uses - fstrict-aliasing, hence the argumentation is absurd.
- nuclx 8y agoIndeed. Support for -fno-strict-aliasing and -fwrapv can be expected for modern C compilers, so I don't see any real hurdles besides the obvious engineering and maintenance effort required to support a robust transpiler.
- steveklabnik 8y agoThere’s also one that exists, so that proves it can be done: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- nuclx 8y agoSo there is hope to overcome the "not as portable as C" showstopper.
- steveklabnik 8y agoYes, though with important caveats: * mrustc doesn't implement a borrow checker. * mrustc's original goal was to bootstrap rustc, and so it's based on Rust 1.19 as of now. So, it's not a panacea, but it is proof that it can be done.
- jononor 8y agoNo borrow checker is intentional. I believe the intended workflow is that one uses the regular Rust compiler for that. Which should be doable for embedded systems (for which I think mrustc is most relevant for), as it supports cross-compiling rather well.
- steveklabnik 8y agoTotally! I think it is the right choice. But I wanted to be clear about what it actually is, that’s all!
- crb002 8y agoCompile to LLVM IR then target C?
- nuclx 8y ago-march=c was apparently removed from LLVM? See https://stackoverflow.com/questions/5180914/llvm-ir-back-to-human-readable-source-language https://stackoverflow.com/questions/5180914/llvm-ir-back-to-... I didn't know that it existed in the first place and what i expected was a bit of a higher level approach. Not even sure if going through Rust -> LLVM IR -> C -> asm would have a negative effect on performance, i.e. if the C code reconstructed from LLVM IR is optimal.