Extracting the abstract syntax tree from GCC • Hacker News Board

Re: Extracting the abstract syntax tree from GCC

#11

Post by rwmj » Mon, Jan 19, 2015, 4:20 PM UTC

jesuslop wrote: post #7

Excuse me, but what's so wrong with the existence of a proprietary gcc backend?

History. RMS was worried that "someone" (basically, Intel) would be able to take the gcc frontend and attach the icc (very fast, proprietary) backend to it, thus creating a compiler which could compile the whole GNU stack, producing very fast code. This would entice people to use a non-free compiler.

Since then LLVM came along and made the whole point moot, since it has a modular front end which can parse all the gcc extensions.

Re: Extracting the abstract syntax tree from GCC

#12

Post by TheDong » Mon, Jan 19, 2015, 4:20 PM UTC

userbinator wrote: post #6

Isn't GCC itself GPL with all the source available? IANAL, but AFAIK that means as long as you release your modifications under GPL too, it doesn't violate any license. Or are they saying that GCC doesn't actually use an AST somehow, which doesn't match at all with my (admittedly limited) knowledge of it? I'm someone who has experience with what can be done in terms of extending/modifying software even without any so…

The issue is not that the plugin wouldn't be gpl; it would. The concern is that the AST dumped is not code, but an artifact, and thus can be used by proprietary software and make proprietary software better.

I could write a program that compiles your gcc-produced AST for a new architecture, and not GPL it because the AST itself probably isn't GPL protected. That's the fear.

Re: Extracting the abstract syntax tree from GCC

#13

Post by tacos » Mon, Jan 19, 2015, 4:23 PM UTC

He played this game with precompiled headers a decade ago and there's STILL barely any support for it in the GNU tools. When a debate around implementing precompiled headers ten years after everyone else gets them requires lawyers to get involved, maybe freedom isn't ringing as clearly as we were promised.

There's something fundamentally weird about the whole dev ecosystem wrt developer productivity. Next time you're sitting in front of an 8 CPU box with an SSD trying to solve a CPAN or library dependency, watching one C file compile once every three seconds, perhaps think about why things always wind up like this.

I super respect Stallman's position but at some point you have to look around (and beyond!) and say "why are we working with crippled tools?" With few exceptions all the core projects are uncontributable at this point. And RMS isn't even the worst; he's just the most consistent and predictable.

Re: Extracting the abstract syntax tree from GCC

#14

Post by GFK_of_xmaspast » Mon, Jan 19, 2015, 4:24 PM UTC

gumby wrote: post #8

spork1 wrote: post #2

comparing emacs to xcode/idea made me lol

> comparing emacs to xcode/idea made me lol Why did it? Emacs is a great development environment. It allows you to focus on the code and supports debugging right next to your code, same as an ide. It is an ide. Emacs lacks some features of xcode/eclipse et al but in exchange it has power they lack. Why shouldn't it gain some of their features? (I am assuming you loled because you considered emacs weaker. My apologies…

I've been programming in emacs since 1992, 2014 was the year I finally gave up and started to move into IDEs (having to target android was the primary motivation for using something else, but I'm rapidly getting spoiled, and am going to shell out for clion once it's done).

There's stuff I miss about emacs, and I'll keep using it for text files and r code and other stuff (it's still my primary python editor until I get around to trying pycharm), but by and large I think I'm done with it for c/c++.

Re: Extracting the abstract syntax tree from GCC

#15

Post by bedatadriven » Mon, Jan 19, 2015, 4:25 PM UTC

userbinator wrote: post #6

Isn't GCC itself GPL with all the source available? IANAL, but AFAIK that means as long as you release your modifications under GPL too, it doesn't violate any license. Or are they saying that GCC doesn't actually use an AST somehow, which doesn't match at all with my (admittedly limited) knowledge of it? I'm someone who has experience with what can be done in terms of extending/modifying software even without any so…

GCC has multiple, rich ASTs that you can access by modifying (and freely distributing) the source, or you can build a plugin that access the AST through the API.

The debate hinges on a very subtle point: GCC does not commit to keeping the plugin API nor the AST structure stable between releases, making it difficult to maintain any software that relies on a specific shape of the plugin API or the ASTs.

Re: Extracting the abstract syntax tree from GCC

#16

Post by willvarfar » Mon, Jan 19, 2015, 4:28 PM UTC

At Symbian we used a GCC backend called GCCXML http://gccxml.github.io/HTML/Index.html to parse our c++ code to drive various scripts and tools.

It never did function bodies, but then we never needed it to.

This was over 10 years ago now; frustrating that GCC has ever made clang necessary :(

Re: Extracting the abstract syntax tree from GCC

#17

Post by hga » Mon, Jan 19, 2015, 4:28 PM UTC

bedatadriven wrote: post #15

userbinator wrote: post #6

Isn't GCC itself GPL with all the source available? IANAL, but AFAIK that means as long as you release your modifications under GPL too, it doesn't violate any license. Or are they saying that GCC doesn't actually use an AST somehow, which doesn't match at all with my (admittedly limited) knowledge of it? I'm someone who has experience with what can be done in terms of extending/modifying software even without any so…

GCC has multiple, rich ASTs that you can access by modifying (and freely distributing) the source, or you can build a plugin that access the AST through the API. The debate hinges on a very subtle point: GCC does not commit to keeping the plugin API nor the AST structure stable between releases, making it difficult to maintain any software that relies on a specific shape of the plugin API or the ASTs.

And the absolute certainty that without getting buy-in from RMS, the API would be constantly changed to frustrate such a AST dumping API. Unless GCC and/or EMACS (using LLVM) gets forked. Again.

Re: Extracting the abstract syntax tree from GCC

#18

Post by hvs » Mon, Jan 19, 2015, 4:29 PM UTC

userbinator wrote: post #6

Isn't GCC itself GPL with all the source available? IANAL, but AFAIK that means as long as you release your modifications under GPL too, it doesn't violate any license. Or are they saying that GCC doesn't actually use an AST somehow, which doesn't match at all with my (admittedly limited) knowledge of it? I'm someone who has experience with what can be done in terms of extending/modifying software even without any so…

I think the point is that people are trying to avoid a fork situation like we had with EGCS and GCC from 1997 to 1999.

Re: Extracting the abstract syntax tree from GCC

#19

Post by bedatadriven » Mon, Jan 19, 2015, 4:30 PM UTC

bedatadriven wrote: post #3

This is precisely what we do in Renjin in order to translate C/Fortran to Java: https://github.com/bedatadriven/renjin/blob/master/tools/gcc... This little plugin simply dumps GCC's gimple to JSON, yielding for example: https://github.com/bedatadriven/renjin/blob/master/tools/gcc... LLVM's design looks very attractive, but for scientific computing Fortran is really important, and AFAICT, LLVM doesn't have an intermed…

I should mention that the only problem we have this approach is that neither the AST structure nor the plugin API is guaranteed to be stable between releases, so if you want to use Renjin's full tool chain, you have to be able to install a copy of GCC 4.6.x locally, which only gets more difficult over time.

This is the actual point of debate: RMS wants to keep these APIs moving targets in order to discourage Intel or whoever from writing a compiler that just shells out to gcc to handle all of the parsing.

Unfortunately, fully GPL'd, open-sourced projects like our own (and who knows how many others that were never even started because of these artificial hurdles) are the ones most affected.

Re: Extracting the abstract syntax tree from GCC

#20

Post by laichzeit0 » Mon, Jan 19, 2015, 4:32 PM UTC

TheDong wrote: post #12

userbinator wrote: post #6

Isn't GCC itself GPL with all the source available? IANAL, but AFAIK that means as long as you release your modifications under GPL too, it doesn't violate any license. Or are they saying that GCC doesn't actually use an AST somehow, which doesn't match at all with my (admittedly limited) knowledge of it? I'm someone who has experience with what can be done in terms of extending/modifying software even without any so…

The issue is not that the plugin wouldn't be gpl; it would. The concern is that the AST dumped is not code, but an artifact, and thus can be used by proprietary software and make proprietary software better. I could write a program that compiles your gcc-produced AST for a new architecture, and not GPL it because the AST itself probably isn't GPL protected. That's the fear.

The fear that someone else might be "better" than you so you're intentionally going to make it impossible for them to even compete is a really dumb argument. Imagine if this was done in sports.

And that seems to have been the whole intention behind this. Make sure no non-GPL backend can be used because god forbid it's better than ours. The shame!