Another related project is the libgccjit backend for rustc: https://github.com/rust-lang/rustc_codegen_gcc
[deleted]
GCC Rust Approved by GCC Steering Committee
51–60 of 300 posts
Re: GCC Rust Approved by GCC Steering Committee
#52Earlier 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...
Rustc has HIR, MIR and then finally llvm IR
Re: GCC Rust Approved by GCC Steering Committee
#53This is great! Gcc support opens up more platforms, more targets, and the opportunity to more easily integrate with the various common embedded toolchains that are built around gcc. And it's free software, for those that care, this matters.
> free software
it seems like this term is misunderstood in English to mean "no money" .. perhaps "Libre Software" is a better starting description here
Re: GCC Rust Approved by GCC Steering Committee
#54I'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 having some diversity in the Rust compiler space is an excellent idea. The rustc monoculture is really bad in the long-term, having multiple compilers allows for creating a much more robust standard (so that implementation bugs doesn't get "baked in" to the language) and benchmarking compile times as well as resulting binaries (in addition to many other benefits).
You're right that GCC Rust will probably be behind rustc for a while, but the sooner you start, the sooner it'll get there. The language isn't gonna "settle down" in that way any time soon, might as well just get going as soon as possible.
Re: GCC Rust Approved by GCC Steering Committee
#55What does a "front-end" mean exactly, in this context?
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…
Very very old compilers like in the early 70's, given that PL.8 and Amsterdam Compiler Toolkit are two well known approaches to this design.
Re: GCC Rust Approved by GCC Steering Committee
#56I'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...
FWIW, it does appear that at least for now, the project is targeting a version of Rust that is substantially behind the current stable version:
> For some context, my current project plan brings us to November 2022 > where we (unexpected events permitting) should be able to support > valid Rust code targeting Rustc version ~1.40 and reuse libcore,
(current stable rustc is 1.62, 1.40 is from Dec. 19, 2019)
Which is in line with what you're saying about gcc likely being behind initially, of course.
I bet it's easier to go from version 1.40 to 1.6x than from version nil to 1.40, though - you have to start somewhere, and the later you start, the longer till you have a viable alternative.
Re: GCC Rust Approved by GCC Steering Committee
#57Earlier quoted context omitted.
Would it ever make sense to build a chip/vm (something like the JVM) designed to run the intermediate code directly?
I would be worried about the intermediate code not being stable over time.
Unless one keeps it stable, like Apple did for watchOS.
However they apparently don't want to keep fixing upstream changes and is now deprecated going forward.
Re: GCC Rust Approved by GCC Steering Committee
#58Why would someone want this? (Honest question)
Another angle is that GNU wants this, because they want GCC to stay relevant and competitive. Rising popularity of LLVM-only Rust gives advantage to their competitor.
No worries, it will keep releavant, now that Apple and Google apparently took out their support from clang, and most other vendors that benefit from MIT aren't that keen into pushing C++ changes upstream, clang is getting a nice third place in C++20 support.
Re: GCC Rust Approved by GCC Steering Committee
#59Earlier quoted context omitted.
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…
Yup. We have microcontrollers that we'd like to write rust on, but we can't because llvm doesn't support the architecture.
A question for curiosity since I don't know much about llvm and specifically the architecture. Does LLVM not support architectures because there is some barrier, or a higher barrier than GCC? And GCC makes it easier to support some architectures or is it just as easy to add the support to LLVM but no one does it because GCC already supports it?
Re: GCC Rust Approved by GCC Steering Committee
#60a naive question - would it be faster than the "regular" rust compiler?