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

21–30 of 138 posts

Re: Rust GCC backend: Why and how

#21

Post by 1718627440 »

torginus wrote: post #18
wahern wrote: post #11

Earlier quoted context omitted.

Not anymore. Modularization is somewhat tangential, but for awhile Stallman did actively oppose rearchitecting GCC to better support non-free plugins and front-ends. But Stallman lost that battle years ago. AFAIU, the current state of GCC is the result of intentional technical choices (certain kinds of decoupling not as beneficial as people might think--Rust has often been stymied by lack of features in LLVM, i.e. de…

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.

Re: Rust GCC backend: Why and how

#23

Post by surajrmal »

1718627440 wrote: post #20
MangoToupe wrote: post #2

I find it shocking that 20 years after LLVM was created, gcc still hasn't moved towards modularization of codegen.

It is a political not a technical decision. Essentially the same like the Linux kernel not encouraging the use of out-of-tree kernel modules. https://gcc.gnu.org/legacy-ml/gcc/2000-01/msg00572.html

And it shows how silly the idea is. gcc still sees plenty of forks from vendors who don't upstream, and llvm sees a lot more commercial participation. Unfortunately the Linux kernel equivalent doesn't exist.

Re: Rust GCC backend: Why and how

#24

Post by hedgehog »

surajrmal wrote: post #23
1718627440 wrote: post #20

Earlier quoted context omitted.

It is a political not a technical decision. Essentially the same like the Linux kernel not encouraging the use of out-of-tree kernel modules. https://gcc.gnu.org/legacy-ml/gcc/2000-01/msg00572.html

And it shows how silly the idea is. gcc still sees plenty of forks from vendors who don't upstream, and llvm sees a lot more commercial participation. Unfortunately the Linux kernel equivalent doesn't exist.

There are several open BSDs.

Re: Rust GCC backend: Why and how

#26

Post by grokx »

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 use by the modern compilers? Or are they built directly in GCC, LLVM, ...?

Re: Rust GCC backend: Why and how

#28

Post by School-Cotton »

hedgehog wrote: post #24
surajrmal wrote: post #23

Earlier quoted context omitted.

And it shows how silly the idea is. gcc still sees plenty of forks from vendors who don't upstream, and llvm sees a lot more commercial participation. Unfortunately the Linux kernel equivalent doesn't exist.

There are several open BSDs.

AFAIK there's no evidence to suggest that permissive vs. copyleft license is the reason for the relative lack of success of the BSDs vs. Linux.

Re: Rust GCC backend: Why and how

#29

Post by bigstrat2003 »

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.

I would describe this more as "trying to prevent others from having non-free software if they wish to", which is a lot more questionable imo.

Re: Rust GCC backend: Why and how

#30

Post by brooke2k »

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.
Post reply on HN