Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC Rust Approved by GCC Steering Committee

gcc.gnu.org

Post reply on HN
Print view View original

41–50 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#41

Post by jcranmer »

sdfhdhjdw3 wrote: post #33
nrclark wrote: post #15

Earlier quoted context omitted.

Compilers are often implemented as a front-end/back-end split. The front-end compiles your input language (C, C++, Rust, etc) down to a low-level language called an Intermediate Representation. Then the back-end of the compiler optimizes the IR and compiles it into object code. A family of compilers will usually share the back-end. This kind of split allows for deduplication across different compilers in the same fam…

Oh damn, THIS is what the "intermediate representation" i keep hearing about is. I knew that Julia uses LLVM. I also knew that Julia has something called IR, but i didn't know what it was. So Julia's IR is probably LLVM's IR...

I suspect Julia has its own IR that is later lowered into LLVM IR. One of the aspects of multiple compilers is that it's basically a massive tower of IRs that get progressively lowered into lower- and lower-level IRs.

Re: GCC Rust Approved by GCC Steering Committee

#42

Post by riffraff »

bitwize wrote: post #9
outside1234 wrote: post #2

Why would someone want this? (Honest question)

GCC already has compiler front ends for Fortran, Ada, Go, and formerly Java. Adding another language, especially one as popular as Rust, couldn't hurt.

also D and Objective-C!

Re: GCC Rust Approved by GCC Steering Committee

#43

Post by bombela »

Galanwe wrote: post #22

Does this mean we could have Rust for AVR? Without all the quirks and schrodinbugs of LLVM AVR on Harvard architectures.

In the past month or so, the latest version of rustc/llvm seems to produce correct machine code. It was very rough for a couple in years though.

Re: GCC Rust Approved by GCC Steering Committee

#44

Post by rob74 »

I'm not sure if this is such a good idea at this point in the evolution of Rust? I mean, Go has a comparatively "tame" pace of changes, but gccgo is still always several months behind gc (which refers to the most-used go compiler, not garbage collection). With the higher volume of changes in Rust, lots of features will be unavailable in gccrust for what will probably feel like ages to some...

Re: GCC Rust Approved by GCC Steering Committee

#45

Post by epage »

lmkg wrote: post #7
outside1234 wrote: post #2

Why would someone want this? (Honest question)

The main source of interest for GCC Rust is because GCC targets more platforms than LLVM. A partially-overlapping interest is using Rust in Linux: Linux targets non-LLVM platforms, but is also deeply tied to GCC and Rust-for-Linux would have a lower barrier to entry if it doesn't require a second toolchain. Long-term, it's considered a strong signal for the health and viability of Rust if it's not strictly tied to on…

Note that for providing more platform support, there is also rustc_codegen_gcc which just replaces LLVM with libgccjust but keeps the rustc frontend.

Re: GCC Rust Approved by GCC Steering Committee

#46

Post by sillysaurusx »

rob74 wrote: post #44

I'm not sure if this is such a good idea at this point in the evolution of Rust? I mean, Go has a comparatively "tame" pace of changes, but gccgo is still always several months behind gc (which refers to the most-used go compiler, not garbage collection). With the higher volume of changes in Rust, lots of features will be unavailable in gccrust for what will probably feel like ages to some...

I think the difference is that Go is less active than Rust.

It might turn out to be a bad idea. But at this point, gcc needs to try something to stay relevant. This is the first piece of news about gcc that made me go "whoa" in the last couple years.

Re: GCC Rust Approved by GCC Steering Committee

#47

Post by kstrauser »

syvon wrote: post #23
brundolf wrote: post #17

Earlier quoted context omitted.

Huh, I didn't realize that

A common misconception is that GCC stands for GNU C Compiler, but it stands for GNU Compiler Collection. Perhaps why you did not realize ;)

GNU C Compiler was the original name. A lot of us probably never bothered updating our mental acronym tables.

Re: GCC Rust Approved by GCC Steering Committee

#48

Post by tendstofortytwo »

bombcar wrote: post #24
colejohnson66 wrote: post #13

Earlier quoted context omitted.

At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if…

Would it ever make sense to build a chip/vm (something like the JVM) designed to run the intermediate code directly?

For a chip, I think you would run into the same problems as Intel iAPX if you did that: https://en.wikipedia.org/wiki/Intel_iAPX_432

Re: GCC Rust Approved by GCC Steering Committee

#49

Post by ruuda »

outside1234 wrote: post #2

Why would someone want this? (Honest question)

Another reason besides platform support, is bootstrapping and verifiable builds. rustc can only be built by a recent rustc, so it is a pain to bootstrap from source if you don't want to trust a big binary.
Post reply on HN