Hacker News Reader

Comment by ncmncm | Hacker News Reader

They say Rust support is blocked by having no RISC-V backed for LLVM, and no Rust Gcc front-end. But I thought there was a working Gcc front-end, just without the borrow checker, which is superfluous for code generation. Maybe it is for an old version of the language, and can't build the current library?

View on HN

AFAIK there's no gcc port underway. There is another Rust compiler[1] but it's not a complete alternative to Rustc, in the short run it was mainly intended to be a way to bootstrap a Rust compiler without needing to go all the way back to the original ocaml implementation of the first Rust compiler. As such, it is only known to output correct binary when running on the code of the Rust 1.19 compiler. This was a really successful project, but it's not something you can use to replace to compile your own arbitrary rust code.

[1] https://github.com/thepowersgang/mrustc

Right, one can use mrustc to compile 1.19, but then they would need to progress through 1.XX -> current. A container chain for bootstrapping the Rust compiler would be a good idea.

Debian Rust maintainer here.

We don't need to bootstrap from scratch, Rust (via LLVM) can cross-compile very easily once riscv64 support is added.

In practise I am already cross-compiling amd64->mips/mipsel for every stable Rust release on my home box, because a native mips rustc compile runs out of memory on those 32-bit machines. [1] The cross-compiled mips works completely fine to build smaller rust packages, e.g cargo [2] ripgrep [3]

[1] https://github.com/rust-lang/rust/issues/56888 [2] https://buildd.debian.org/status/package.php?p=cargo [3] https://buildd.debian.org/status/package.php?p=rust-ripgrep

Yeah back with 1.14 or so I set up some cross (and native) toolchains for mipsel with the intent of putting some stuff on my ER-X. While it was a giant pain in the dick with the unsupported version of Debian Ubiquiti was using, it was doable. Cross compiling on Debian has come a long way (altho I'm using crosstool-ng on OSX these days which is fairly slick).

This is probably what you mean:

https://github.com/thepowersgang/mrustc

It's still a work in progress, with only x86 even supported. It's not a GCC frontend, it generates C, and is based on an old version of rust (1.19). Right now I think it's only useful to bootstrap rust, but that doesn't help you get a backend for another architecture.

Why not? Just bootstrap but on another architecture?

Just because you may have a functional compiler running on a another architecture, doesn't mean the compiler actually outputs code FOR that architecture. The compiler would still only support the architectures it did when you bootstrapped it, which in that case would not include that specific architecture.

The Rust compiler is a cross-compiler by default, so the usual way that you bootstrap on a new platform is to add it to the existing compiler, and then cross-compile to the new architecture. Which is what I read your parent as suggesting.

The discussion is not about bootstrapping. Bootstrapping using mrustc on riscv64 would get you a working rust 1.19 compiler that runs on riscv64 and knows how to emit x86 code. It wouldn't even allow you to go up to the latest version. That's not very useful, Debian already has a rust compiler that emits x86, it needs a rust compiler that emits riscv64.

Right. They could add the riscv64 backend to the current compiler, and then cross-compile it from x86_64, meaning that the bootstrap chain for riscv64 would start at 1.37.0. No mrustc even needed.

That said, I feel like we may be talking past each other... what I'm saying is, to get support for riscv64, you don't need to do a full new bootstrap. Maybe I'm misunderstanding the point of the thread.

That is the usual case, but some people don't want to download any binary blob that's not a C compiler.

The lack of LLVM backend surprises me. How much work is it to add a backend with 60 instructions (and few addressing modes)? It's clearly far more than I would have guessed.

LLVM has an experimental Riscv backend. Adding it is easy. QAing it to the point that is can be considered non experimental is a lot of work.

Nightly Rust already has basic RISC-V support, but the problem is Rust's libc binding is not yet ported to RISC-V. Without libc, Rust's std will not be usable, that's the main blocker here. While the theory is you don't require std to compile a Rust program, most, if not all, Rust programs leverage std in some extent.

Reply on news.ycombinator.com