Rust compiler walk-through – Introduction | Hacker News Reader

Rust compiler walk-through – Introduction

gchp.ie

88 pointsingve14 comments

Does any one know if there is a plan for a GCC Rust Frontend?

I doubt it. Unless the GNU team decided to add it, I don't think there's much incentive. Are there targets out there that gcc supports which aren't supported by LLVM? Probably not too many. Commercially, LLVM is much more attractive than GCC, so semiconductor companies which make CPUs/uCs/DSPs/GPUs/FPGAs/etc are probably more likely to create an LLVM backend than a gcc one.

> Are there targets out there that gcc supports which aren't supported by LLVM? Probably not too many

Plenty in the embedded space. Just compare the GCC backend list at https://gcc.gnu.org/backends.html to what LLVM supports ("only" X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore).

The embedded space is very diverse, and even if LLVM backend support is good it's still nowhere near GCC. They're pretty niche of course and LLVM does a good job of supporting the mainstream architectures (and even a bit more). Still, if you're in embedded development not being supported by GCC is limiting.

I could be wrong but I'd wager that there's some support for many of those backends that's just not upstreamed to LLVM.

You can say the same thing for GCC too, it's just that both of the pools (merged into trunk and not) are much larger.

Yeah. Trunk LLVM doesn't even have AVR support, so no Rustduino.

A prominent member of the rust community has been publishing a series on getting rust to target their Uno: http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-u...

If a compiler supports ARM and Thumb, it covers a majority of modern embedded platforms. The days of 8- and 16-bit microcontrollers are coming to an end -- 32-bit Cortex-Mx chips are very competitive on price and power consumption and much more capable.

There are two nascent alternative Rust compiler projects that I know of. One is https://github.com/thepowersgang/mrustc, which does not aim to be a GCC or LLVM front-end, and seems aimed at bootstrapping rust on platforms with only C/C++ support. The author of this alt compiler says they're able to parse and typecheck libcore (the small OS independent part of the standard library). They are working on codegen so they can start making use of the rustc compiler tests. I don't think they aim to implement the borrow checker, though, because their goal is bootstrapping rustc on other platforms, and the borrow checking can be verified using a different compiler.

There's also a frequent user of the rust irc channels who is experimenting with writing a GCC front-end for rust. I don't think any code for that is public yet, and I don't know how far along they are.

I mean, I'm guessing here, but wouldn't simplest way be starting mid-way in the existing Rust compiler to port an intermediate language to GCC? Straight-up compile it to GCC C or whatever GCC does internally. That way, you get the parsing, analysis, etc for free plus any improvements they make. Lots of other languages used this approach.

I'm pretty sure mrustc isn't targeting GCC as a backend, but I'm not sure.

I don't know what approach is being taken by the person working on a GCC backend, but it's entirely possible what you've described is what they're doing.

> I'm pretty sure mrustc isn't targeting GCC as a backend, but I'm not sure.

I'm pretty sure your statement is somewhat paradoxical :)

Wow, that's a lot of passes in the compiler. Seems to do most pretty fast. I look forward to reading this series. Especially, how they handle safety stuff worth porting to other languages.

Yeah! I was surprised by the amount. When I read things now about compiler speed, I'm looking through a different lens now that I have an idea of the sheer amount of work it's doing. Pretty impressive.

Reply on news.ycombinator.com