-
> so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way?
At a high level, this is correct: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...
> If gccrs interprets a program differently from rustc, this is considered a bug.
I don't believe they are only reading the frontend, but using the reference first, then looking to the implementation second, and asking a lot of questions along the way.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
That is actually going to happen for rustc itself via the rustc_codegen_gcc project (https://github.com/rust-lang/rustc_codegen_gcc), this post is about a different project that writes a "from scratch" rust frontend/compiler for the GCC project in C++ . They both compile rust code with GCC as a backend, but one uses the normal rustc/cargo tools, and the other is a separate compiler with a separate cargo shim.
-
https://github.com/thepowersgang/mrustc is already providing that; it targets 1.54 right now, which is farther along than this project (though obviously that may not be always true in the future).
-
> So it would be enough to support the subset of Rust that gets actually used in the kernel. I would imagine they would be very conservative about which features get used and adopt at a much slower speed.
For now, it's the opposite: the kernel needs several Rust features which aren't even stable yet (https://github.com/Rust-for-Linux/linux/issues/2). But I agree that, after Rust has been in use in the kernel for a while (and it no longer needs any unstable features), the kernel developers are going to be somewhat conservative about which features are required (but not about which features are used; they probably will use a lot of conditional compilation, like they already do for gcc/clang, see the compiler-*.h files).
-
Cargo support for gccrs is part of this project:
https://github.com/Rust-GCC/cargo-gccrs
Moreover, modules are less interesting to me in embedded development as is access to Rust's borrow checker for gaining certainty of small portions of larger projects, which are written in other languages.
-
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
Related posts
-
Why do lifetimes need to be leaky?
-
Adding a Rust compiler front end to GCC
-
Take your first steps with Rust
-
Why am I writing a Rust compiler in C?
-
How hard would it be to port the Rust toolchain to a new non-POSIX OS written in Rust and get it to host its own development? What would that process entail?