GCC Rust Approved by GCC Steering Committee • Hacker News Board

Re: GCC Rust Approved by GCC Steering Committee

#61

Post by steveklabnik » Mon, Jul 11, 2022, 4:34 PM UTC

ruuda wrote: post #49

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.

https://github.com/thepowersgang/mrustc is already providing that; it targets 1.54 right now, which is farther along than this project (though obviously that may not be always true in the future).

Re: GCC Rust Approved by GCC Steering Committee

#62

Post by tcmart14 » Mon, Jul 11, 2022, 4:35 PM UTC

outside1234 wrote: post #2

Why would someone want this? (Honest question)

I didn't see this mentioned in any replies, but I think another reason why this is wanted is for Rust in the linux kernel development. If Rust can compile using GCC tooling, it should be easier to integrate into the build process for the Linux kernel. As it stands now, if Linux kernel development allowed Rust in areas of the kernel outside of modules and drivers, you need the GCC tool chain to build the kernel and the llvm toolchain. So it also meets a requirement, or at least greases the wheels, for the possibility of getting Rust into the Linux kernel.

Re: GCC Rust Approved by GCC Steering Committee

#63

Post by rascul » Mon, Jul 11, 2022, 4:40 PM UTC

mistrial9 wrote: post #53

dleslie wrote: post #8

This 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

The term has been around for decades now, and seems to be fairly well understood in the tech world. It doesn't take much to say "free as in speech, not beer" to the few people left who need to understand it.

Re: GCC Rust Approved by GCC Steering Committee

#64

Post by cozzyd » Mon, Jul 11, 2022, 4:40 PM UTC

pjmlp wrote: post #58

pornel wrote: post #30

Earlier quoted context omitted.

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.

Apple Clang is already a completely different beast than upstream, right? At least the version numbers are nonsensical unnecessarily complicating feature support checks in my experience as someone who doesn't own any Macs but writes software that others insist on trying to compile on a Mac...

Re: GCC Rust Approved by GCC Steering Committee

#65

Post by wging » Mon, Jul 11, 2022, 4:41 PM UTC

Alghranokk wrote: post #20

pca006132 wrote: post #10

Earlier quoted context omitted.

Indeed, but I think they should first create a standard?

Rust already has stable standards. There's Rust editions 2015 (1.0), 2018 (1.31.0), and 2021 (1.56.0).

Unfortunately that's not quite the same thing as a standard in the sense that is meant here. A 'standard' is a written document that explains how the language should work. A standard that just says "the compiler is correct if it compiles code the way that rustc 1.xy does" is technically unambiguous in that it provides a procedure by which a compiler author can check their work, but leaves quite a bit on the table and is probably the wrong goal to aim at in the long term, even if it enables forward progress for now. (For example, we know rustc contains bugs; do we want gcc-rust to include all the bugs, or should it differ from rustc in that respect? Which behaviors are bugs, which are undesired but accepted quirks of the language, and which are intentional? For that matter, it's unreasonable to expect gcc-rust to produce binaries that are byte-for-byte identical, so what other mechanism should be used to determine equivalence?)

(btw, there's also https://doc.rust-lang.org/reference/)

Re: GCC Rust Approved by GCC Steering Committee

#66

Post by sfink » Mon, Jul 11, 2022, 4:43 PM UTC

colejohnson66 wrote: post #13

sdfhdhjdw3 wrote: post #11

What 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…

Note that the language independence of the middle layer(s) is often incomplete. Language-level constructs sometimes get smuggled through the intermediate layer and get translated in code generation. Or the middle layer is theoretically generic but valid variants that haven't been used before are buggy or unimplemented.

I think Rust on LLVM has a major example of this? IIUC, it's a big problem to turn on strict aliasing because LLVM doesn't actually implement it correctly, it just works well enough for C/C++ etc.? (But I'm no expert.)

Still, the frontend/backend split gets you a lot closer to supporting all of the l*t pairs than the all-in-one approach. Porting is a matter of fixing bugs and filling in missing parts rather than starting from scratch.

Re: GCC Rust Approved by GCC Steering Committee

#67

Post by colejohnson66 » Mon, Jul 11, 2022, 4:45 PM UTC

sfink wrote: post #66

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…

Note that the language independence of the middle layer(s) is often incomplete. Language-level constructs sometimes get smuggled through the intermediate layer and get translated in code generation. Or the middle layer is theoretically generic but valid variants that haven't been used before are buggy or unimplemented. I think Rust on LLVM has a major example of this? IIUC, it's a big problem to turn on strict aliasi…

For sure, leaky abstractions will get through; Rust has had quite a few issues LLVM (you mention one), but it's still a lot better than the all-in-one system we had before.

Re: GCC Rust Approved by GCC Steering Committee

#68

Post by cogman10 » Mon, Jul 11, 2022, 4:48 PM UTC

maxyurk wrote: post #60

a naive question - would it be faster than the "regular" rust compiler?

I can't seem to find any benchmarks around it. I'm assuming as this gets further integrated into GCC, you'll start to see those crop up.

Re: GCC Rust Approved by GCC Steering Committee

#69

Post by kergonath » Mon, Jul 11, 2022, 4:48 PM UTC

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?

Something like a Low-Level Virtual Machine?

Short answer, it’s feasible in theory, but usually suboptimal.

Re: GCC Rust Approved by GCC Steering Committee

#70

Post by Twirrim » Mon, Jul 11, 2022, 4:50 PM UTC

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?

Been there, done that!

https://en.wikipedia.org/wiki/Jazelle

Jazelle was an instruction set extension to allow natively running java bytecode on Arm processors. Arm never seemed to give it any proper care and attention necessary for it to make any actual market impact, they didn't even publish the ABI.

Transmeta, that used to employ Linus Torvalds at one stage, had Code Morphing Software: https://en.wikipedia.org/wiki/Transmeta#Code_Morphing_Softwa...

It was built in to the silicon, that essentially operated as a full JIT for x86 software, translating to back-end VLIW instruction set. Transmeta seemed heavy on the marketing and buzz (hiring Linus was very much a marketing move), light on the actual execution. Crusoe didn't even remotely live up to their own buzz and it just about killed off their chances of success.