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

Rust GCC backend: Why and how

blog.guillaume-gomez.fr

Post reply on HN
Print view View original

31–40 of 138 posts

Re: Rust GCC backend: Why and how

#31

Post by gpderetta »

brooke2k wrote: post #30
grokx wrote: post #26

When I studied compiler theory, a large part of the compilation involved a lexical analyser (e.g. `flex`) and a syntax analyser (e.g. `bison`), that would produce an internal representation of the input code (the AST), used to generate the compiled files. It seems that the terminology as evolved, as we speak more broadly of frontends and backends. So, I'm wondering if Bison and Flex (or equivalent tools) are still in…

Not sure about GCC, but in general there has been a big move away from using parser generators like flex/bison/ANTLR/etc, and towards using handwritten recursive descent parsers. Clang (which is the C/C++ frontend for LLVM) does this, and so does rustc.

I believe that GCC also moved to a handwritten parser, at least for c++, a couple of decades ago.

Re: Rust GCC backend: Why and how

#32

Post by [deleted] »

grokx wrote: post #26

When I studied compiler theory, a large part of the compilation involved a lexical analyser (e.g. `flex`) and a syntax analyser (e.g. `bison`), that would produce an internal representation of the input code (the AST), used to generate the compiled files. It seems that the terminology as evolved, as we speak more broadly of frontends and backends. So, I'm wondering if Bison and Flex (or equivalent tools) are still in…

[deleted]

Re: Rust GCC backend: Why and how

#33

Post by quamserena »

grokx wrote: post #26

When I studied compiler theory, a large part of the compilation involved a lexical analyser (e.g. `flex`) and a syntax analyser (e.g. `bison`), that would produce an internal representation of the input code (the AST), used to generate the compiled files. It seems that the terminology as evolved, as we speak more broadly of frontends and backends. So, I'm wondering if Bison and Flex (or equivalent tools) are still in…

Not really. Here’s a comparison of different languages: https://notes.eatonphil.com/parser-generators-vs-handwritten...

Most roll their own for three reasons: performance, context, and error handling. Bison/Menhir et al. are easy to write a grammar and get started with, but in exchange you get less flexibility overall. It becomes difficult to handle context-sensitive parts, do error recovery, and give the user meaningful errors that describe exactly what’s wrong. Usually if there’s a small syntax error we want to try to tell the user how to fix it instead of just producing “Syntax error”, and that requires being able to fix the input and keep parsing.

Menhir has a new mode where the parser is driven externally; this allows your code to drive the entire thing, which requires a lot more machinery than fire-and-forget but also affords you more flexibility.

Re: Rust GCC backend: Why and how

#34

Post by pklausler »

grokx wrote: post #26

When I studied compiler theory, a large part of the compilation involved a lexical analyser (e.g. `flex`) and a syntax analyser (e.g. `bison`), that would produce an internal representation of the input code (the AST), used to generate the compiled files. It seems that the terminology as evolved, as we speak more broadly of frontends and backends. So, I'm wondering if Bison and Flex (or equivalent tools) are still in…

Table-driven parsers with custom per-statement tokenizers are still common in surviving Fortran compilers, with the exception of flang-new in LLVM. I used a custom parser combinator library there, inspired by a prototype in Haskell's Parsec, to implement a recursive descent algorithm with backtracking on failure. I'm still happy with the results, especially with the fact that it's all very strongly typed and coupled with the parse tree definition.

Re: Rust GCC backend: Why and how

#35

Post by dhosek »

giancarlostoro wrote: post #9
colejohnson66 wrote: post #5

Earlier quoted context omitted.

Somewhat. Stallman claims to have tried to make it modular,[0] but also that he wants to avoid "misuse of [the] front ends".[1] The idea is that you should link the front and back ends, to prevent out-of-process GPL runarounds. But because of that, the mingling of the front and back ends ended up winning out over attempts to stay modular. [0]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... [1]: https…

That sounds like Stallman wants proprietary OSS ;) If you're going to make it hard for anyone anywhere to integrate with your open source tooling for fear of commercial projects abusing them and not ever sharing their changes, why even use the GPL license?

This is a big part of why I’ve always eschewed GPL.

Re: Rust GCC backend: Why and how

#36

Post by throwaway17_17 »

lionkor wrote: post #22
1718627440 wrote: post #19

I don't necessary like the focus on Rust, but if it happens, then we need to have support in the free compiler!

Why not? Like what about the technology or ecosystem do you disagree with

Not parent, but I share the ambivalence (at best) or outright negativity (at worst) toward the focus on Rust. It is a question of preference on my part, I don’t like the language and I do not want to see it continue to propagate through the software I use and want to control/edit/customize. This is particularly true of having Rust become entrenched in the depths of the open-source software I use on my personal and work machines. For me, Rust is just another dependency to add to a system and it also pulls along another compiler and the accompanying LLVM. I’m not going to learn a language that I disagree with strongly on multiple levels, so the less Rust in my open source the more control I retain over my software. So for me the less entrenched Rust remains the more ability I keep to work on the software I use.

That said, if Rust is going to continue entrenching itself in the open source software that is widely in use, it should at least be able to be compiled with by the mainline GPL compiler used and utilized by the open source community. Permissive licenses are useful and appreciated in some context, but the GPL’d character of the Linux stack’s core is worth fighting to hold onto.

It’s not Rust in open source I have a problem with, it is Rust being added to existing software that I use that I don’t want. A piece of software, open source, written in Rust is equivalent to proprietary software from my perspective. I’ll use it, but I will always prefer software I can control/edit/hack on as the key portions of my stack.

Re: Rust GCC backend: Why and how

#37

Post by lionkor »

throwaway17_17 wrote: post #36
lionkor wrote: post #22

Earlier quoted context omitted.

Why not? Like what about the technology or ecosystem do you disagree with

Not parent, but I share the ambivalence (at best) or outright negativity (at worst) toward the focus on Rust. It is a question of preference on my part, I don’t like the language and I do not want to see it continue to propagate through the software I use and want to control/edit/customize. This is particularly true of having Rust become entrenched in the depths of the open-source software I use on my personal and wo…

> I disagree with strongly on multiple levels

Fair enough, but what are those disagreements? I was fully in the camp of not liking it, just because it was shoved down every projects throat. I used it, it turns out its fantastic once you get used to the syntax, and it replaced almost all other languages for me.

I just want to know if there are any actual pain points beyond syntax preference.

Edit: I partially agree with the compiler argument, but it's open source, and one of the main reasons the language is so fantastic IS the compiler, so I can stomach installing rustc and cargo.

Re: Rust GCC backend: Why and how

#38

Post by [deleted] »

mastax wrote: post #16

> On that note: GCC doesn't provide a nice library to give access to its internals (unlike LLVM). So we have to use libgccjit which, unlike the "jit" ("just in time", meaning compiling sub-parts of the code on the fly, only when needed for performance reasons and often used in script languages like Javascript) part in its name implies, can be used as "aot" ("ahead of time", meaning you compile everything at once, all…

[deleted]

Re: Rust GCC backend: Why and how

#39

Post by Y_Y »

Croak wrote: post #15
colejohnson66 wrote: post #5

Earlier quoted context omitted.

Somewhat. Stallman claims to have tried to make it modular,[0] but also that he wants to avoid "misuse of [the] front ends".[1] The idea is that you should link the front and back ends, to prevent out-of-process GPL runarounds. But because of that, the mingling of the front and back ends ended up winning out over attempts to stay modular. [0]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... [1]: https…

When gcc was built most compilers were proprietary. Stallman wanted a free compiler and to keep it free. The GPL license is more restrictive, but it's philosophy is clear. At the end of the day the code's writer can choose if and how people are allowed to use it. You don't have to use it, you can use something else or build you own. And maybe, just maybe Linux is thriving while Windows is dying because in the Linux e…

> At the end of the day the code's writer can choose if and how people are allowed to use it.

If it's free software then I can modify and use it as I please. What's limited is redistributing the modified code (and offering a service to users over a network for Afferro).

https://www.gnu.org/philosophy/free-sw.en.html#fs-definition

Re: Rust GCC backend: Why and how

#40

Post by Analemma_ »

1718627440 wrote: post #21
torginus wrote: post #18

Earlier quoted context omitted.

Personally, I think when you are making bad technical decisions in service of legal goals (making it harder to circumvent the GPL), that's a sure sign that you made a wrong turn somewhere.

Why? When your goal is to have free software, having non-free software with better architecture won't suit you.

This argument has been had thousands of times across thousands of forums and mailing lists in the preceding decades and we're unlikely to settle it here on the N + 1th iteration, but the short version of my own argument is that the entire point of Free Software is to allow end users to modify the software in the ways it serves them best. That's how it got started in the first place (see the origin story about Stallman and the Printer).

Stallman's insistence that gcc needed to be deliberately made worse to keep evil things from happening ran completely counter to his own supposed raison d'etre. Which you could maybe defend if it had actually worked, but it didn't: it just made everyone pack up and leave for LLVM instead, which easily could've been predicted and reduced gcc's leverage over the software ecosystem. So it was user-hostile, anti-freedom behavior for no benefit.

Post reply on HN