Rust compiler walk-through – Introduction(gchp.ie)
gchp.ie
Rust compiler walk-through – Introduction
https://gchp.ie/2016/08/09/rust-compiler-walkthrough-introduction/
2 comments
Does any one know if there is a plan for a GCC Rust Frontend?
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.
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 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 :)
I'm pretty sure your statement is somewhat paradoxical :)
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.
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.
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.
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.