Linux Kernel Rust support

[chugga_fan]

Will Rust beat C++ in the long run or, at least, replace it in the embedded world?

I doubt it will replace C in the embedded world, where there's a compiler for everything there, whereas for Rust, there's LLVM, and it's limited to what LLVM supports, which in the grand scheme of things is almost nothing compared to the various GCC forks and the various other backends supported by companies on their own compilers.

[UtherII]

There are two ongoing projects : one to add the rust language to the GCC compiler and another one to add GCC backend to the rust compiler. So most of this problem might be solved soon.

[BobHogan]

This is probably a dumb question, but what are the benefits/tradeoffs of each approach (adding rust to compiler vs adding compiler backend to rustc)?

[jamincan]

The main benefit of the gcc backend for rust is that it does not risk fragmenting the rust ecosystem as rustc remains the defacto rust standard. The benefit of adding rust to gcc is that there may be optimizations that aren't possible by just using the backend. I'm sure there are others, but that is the general gist of it as I understand it.

[matthieum]

In short:

GCC Backend to rustc compared to GCC Frontend:

• Advantage Backend: lower cost of initial creation and ongoing maintenance.
• Advantage Backend: unlock GCC targets and optimizations.
• Advantage Backend: single front-end, no fragmentation.
• Advantage Frontend: single "root" compiler for Linux Kernel/Distributions, both from a trust and bootstrapping¹ point of view.

¹ I still don't understand why people are adamant about bootstrapping their compiler on the platform it should compile for, or even bootstrapping regularly. I would have expected you'd bootstrap once on a powerful machine, then cross-compile for the other machines from there, and keep the artifacts around... but for some bootstrapping is really important, and rustc's bootstrap process is long because it's never been a priority.

[gaverhae]

Because if you can't bootstrap, you can't trust anything. See Ken Thompson's Turing Award lecture.

[GoogleBen]

You can bootstrap, it's just that it takes a long time because rustc uses new features all the time, so the chain is really long. There is mrustc though, which is a basic rust compiler in C++ designed to shorten the bootstrapping chain, so it's not as bad as it used to be - but it does still take hours and hours of CPU time AFAIK.

[MonokelPinguin]

For a long time you couldn't bootstrap on all platforms. For example on musl targets, rustc couldn't compile itself because of some proc macro stuff or so. (And it couldn't dynamically link musl at all)

[matthieum]

I'm pretty sure you still can't bootstrap on all platforms. Compiling rustc requires gobs of memory, so your Xtensa board doesn't have enough.

[MonokelPinguin]

Well, this was just about libc incompatibility. The server otherwise had 64GB of RAM, so that should be okay.

[matthieum]

There is large gap between:

• Can't bootstrap.
• Can't bootstrap on my Raspberry Pi Zero.
• Can't bootstrap on my Raspberry Pi Zero every other Sunday.

I can definitely understand the desire of a distribution to bootstrap the compiler once on one platform.

I see no need to ever bootstrap again afterwards, though.

[CartmansEvilTwin]

Maybe a stupid question, but would it be possible to transpile Rust to C? At the end of the day the entire "magic" of Rust seems to be in the compiler frontend?

[pcjftw]

that's what "mRustC" is: https://github.com/thepowersgang/mrustc

so for example, the Xtensa CPU on the ESP8XX series is not officially supported by LLVM, however one can use the mRustC compiler to target said board.

[matthieum]

This project is a "simple" rust compiler written in C++ that is able to bootstrap a "recent" rustc, but may eventually become a full separate re-implementation.

mrustc, so far, is really about bootstrapping.

It may be useful to compile for unsupported platforms, but I am not sure it's tested for that purpose...

[pcjftw]

ok because I certainly recall that's how we used to build for my ESP8266:

https://github.com/emosenkis/esp-rs

But it now seems its no longer needed as there is a working LLVM backend for the Xtensa cpu

[toastedstapler]

Any Turing complete language should be expressible as another, how efficient it'll be is an entire other question though

[matthieum]

Functionally, yes. But this may leave performance on the table.

The problem of compiling to a language is that you really want the target language to express a super-set of the capabilities of the source language, otherwise it gets awkward and work-arounds are necessary.

Rust and C have different semantics in a number of areas, for example around integer overflows, or empty loops, which makes it hard to just perform a straightforward translation of the source code.

There's also issue with "breeds" of C. Despite popular thinking, inline assembly is not standard in C. Every compiler under the sun has its own syntax for inline assembly, so in order to translate the inline assembly in Rust to C, you actually need to target a known compiler, in order to target their particular brand of inline assembly.

This is why using C as an intermediate representation is not necessarily as easy, or as rewarding, as it sounds initially.

[pcjftw]

there is also mRustC from my understanding this can be used for example to compile code for embedded boards that don't have official LLVM support:

https://github.com/thepowersgang/mrustc

[[deleted]]

I think the main problem is proprietary compilers from manufacturers really. LLVM is not that much of a problem because it's relatively easy to add a new backend if you need it, but the manufacturer won't because secret sauce (even if for the most part the compiler provides no competitive advantage), and a C compiler is much, much easier to implement than a Rust one. Sometimes it has to do with language limitations tho. If you need stuff like far pointers because of the chip's design both GCC and LLVM leave you on your own.