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

81–90 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#81

Post by nicoburns »

dolni wrote: post #78
nicoburns wrote: post #75

Earlier quoted context omitted.

> free as in speech, not beer I can never remember which way around this is. I think the "beer" is supposed to be free in the monetary sense and "speech" is supposed to be free in the rights/liberty sense, but the analogy doesn't actually convey this: - Speech is normally both monetarily free and (in certain places) a right - Beer is normally neither monetarily free or a right. But may make you "feel" free, which is…

The first amendment to the US Constitution provides very strong protection for the right to free speech. Presumably that is the origin of "free as in speech".

Right, but what about "free as in beer"?

Re: GCC Rust Approved by GCC Steering Committee

#82

Post by cozzyd »

tcmart14 wrote: post #59
potatochup wrote: post #27

Earlier quoted context omitted.

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?

The vendor sometimes does this and GCC is much more standard in the embedded space. And crucially, it's required to be open source.

For example, for arm-none-eabi, ARM provides a GCC toolchain (https://developer.arm.com/Tools%20and%20Software/GNU%20Toolc...) but makes you purchase the LLVM-based one (https://developer.arm.com/Tools%20and%20Software/Arm%20Compi...). Now I'm fairly certain there's an open-source way to target ARM microcontrollers with LLVM but you can't download it from ARM...

Re: GCC Rust Approved by GCC Steering Committee

#83

Post by steveklabnik »

rob74 wrote: post #18
pca006132 wrote: post #10

Earlier quoted context omitted.

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

If not a standard, then at least a specification. This discussion is from 2020, so I'm not sure if it's still up to date: https://users.rust-lang.org/t/where-is-the-rust-language-spe... "For the most part though, rustc itself is the spec" - so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way? And try to keep up with all the changes which will inevitabl…

> so, for implementing the GCC frontend, read the current LLVM frontend really carefully and do everything the same way?

At a high level, this is correct: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

> If gccrs interprets a program differently from rustc, this is considered a bug.

I don't believe they are only reading the frontend, but using the reference first, then looking to the implementation second, and asking a lot of questions along the way.

Re: GCC Rust Approved by GCC Steering Committee

#84

Post by cardanome »

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...

First of all, let's hope Rust development slows down in the long term as it matures. I think it is already starting as dependence on nightly is less of a thing than it used to be.

Secondly, Rust has strong backwards compatibility guarantees and you can pin your code to a certain edition.

Thirdly, one big use case for gcc would be compiling the Linux kernel that might contain Rust in the future. So it would be enough to support the subset of Rust that gets actually used in the kernel. I would imagine they would be very conservative about which features get used and adopt at a much slower speed.

Re: GCC Rust Approved by GCC Steering Committee

#85

Post by cogman10 »

tcmart14 wrote: post #59
potatochup wrote: post #27

Earlier quoted context omitted.

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?

It's a mixture of problems.

GCC targets more platforms than LLVM, that much is true. But beyond that, it's pretty common in the microcontroller world for a vendor to release their own specially patched version of GCC blessed for a given platform. They simply aren't doing that for the LLVM.

Those blessed GCCs aren't often seeing the hacks merged upstream.

Here's one such example:

https://www.ti.com/tool/MSP430-GCC-OPENSOURCE?keyMatch=gcc&a...

Re: GCC Rust Approved by GCC Steering Committee

#86

Post by chrisoverzero »

nicoburns wrote: post #75
rascul wrote: post #63

Earlier quoted context omitted.

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.

> free as in speech, not beer I can never remember which way around this is. I think the "beer" is supposed to be free in the monetary sense and "speech" is supposed to be free in the rights/liberty sense, but the analogy doesn't actually convey this: - Speech is normally both monetarily free and (in certain places) a right - Beer is normally neither monetarily free or a right. But may make you "feel" free, which is…

It’s not as complex as you’re choosing to make it. When someone tells you, “There’s free beer at Oktoberfest,” is your first thought that the beer has no monetary cost, or that the beer is unencumbered by particular legal restrictions?

Now someone tells you, “There’s free speech at Oktoberfest.” Is your first thought that there’s no monetary cost to expression, or that the expression is unencumbered by particular legal restrictions?

(Happily, Oktoberfest has both.)

Think of them as the _slightly_ longer "Free as in 'free beer' " and "Free as in 'free speech' ". When beer is described as “free,” it’s understood to be gratis. When speech is described as free, it’s understood to be libre. These are used as examples for more ambiguous situations, since software can be one, the other, both, or neither.

Re: GCC Rust Approved by GCC Steering Committee

#87

Post by eddd-ddde »

nicoburns wrote: post #75
rascul wrote: post #63

Earlier quoted context omitted.

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.

> free as in speech, not beer I can never remember which way around this is. I think the "beer" is supposed to be free in the monetary sense and "speech" is supposed to be free in the rights/liberty sense, but the analogy doesn't actually convey this: - Speech is normally both monetarily free and (in certain places) a right - Beer is normally neither monetarily free or a right. But may make you "feel" free, which is…

Free as in beer, as when one refers to 'free beer' it's one that you don't pay for. When one says 'free speech' it's one that allows you to do what you want.

Former is gratis, latter is libre.

Re: GCC Rust Approved by GCC Steering Committee

#88

Post by iex_xei »

nicoburns wrote: post #81
dolni wrote: post #78

Earlier quoted context omitted.

The first amendment to the US Constitution provides very strong protection for the right to free speech. Presumably that is the origin of "free as in speech".

Right, but what about "free as in beer"?

If I buy you a beer, that's free beer for you.

Re: GCC Rust Approved by GCC Steering Committee

#89

Post by rgoulter »

nicoburns wrote: post #75
rascul wrote: post #63

Earlier quoted context omitted.

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.

> free as in speech, not beer I can never remember which way around this is. I think the "beer" is supposed to be free in the monetary sense and "speech" is supposed to be free in the rights/liberty sense, but the analogy doesn't actually convey this: - Speech is normally both monetarily free and (in certain places) a right - Beer is normally neither monetarily free or a right. But may make you "feel" free, which is…

> Beer is normally neither monetarily free

TBH the main place I've seen the phrase "free beer" is a Simpson's joke: people stand in front of a sign saying "free beer", but after Homer drinks many cups, the sign is revealed in full to say "alcohol-free beer, $5/cup".

It's understood that beer normally costs money, so the setup of the joke is that "free beer" is understood without explanation as "beer without costing money".

Re: GCC Rust Approved by GCC Steering Committee

#90

Post by jcranmer »

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…

> 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.)

It's noalias (C99's restrict code, in essence), that you're thinking of, not C/C++ strict aliasing rules.

Post reply on HN