Competition Among Open Source Compilers: The BSD Issue | Hacker News Reader

Competition Among Open Source Compilers: The BSD Issue

informit.com

45 pointsjast27 comments

The FreeBSD people are rigorously testing LLVM, with the goal to replace GCC as soon as possible (for the base system only). At the moment, the base system compiles and runs for some architectures, as noted in http://wiki.freebsd.org/BuildingFreeBSDWithClang#head-afded4...

Any feeling why llvm gets the call over pcc? Certainly a lot of energy going into llvm.

LLVM is designed to make fast machine code. PCC is designed to make reasonable machine code in a way that's easier to verify as being correct. They address two different issues.

Also, LLVM has backing from Apple. That helps.

Another C compiler is tcc (http://bellard.org/tcc/) is a tiny C99 compiler that can be used as scripting language.

Bellard is one of my programming super heroes.

I could hardly qualify tcc as maintainable. Remember that this piece of code won the ioccc.

There 2 different tcc, from the same guy. Only one gone to iocc. the second is fine.

And cparser+libfirm is another one: http://freshmeat.net/projects/firm_cparser/

printer-friendly single-page version: http://www.informit.com/articles/printerfriendly.aspx?p=1168...

It's far from a trivial task but one thing I keep wondering about LLVM is - what happens if they worked on (optional) incremental parsing/compiling?

Seeing the errors as you type is pretty handy in Java so I figure it'd be pretty nice in C or C++.

It also means you'd have enough information about what's happening at the point you are editing to do some pretty impressive things in terms of autocompletion - there's still a lot of autocompletion in C++ that there is no open source solution (as far as I've seen from looking around for a while).

And with the appropriate debugging hooks you could implement something like edit-and-continue from Visual Studio. I haven't used that in years, but it'd be a nice feature to have.

I think that templates would make it a complex problem, but I can dream. Or I can start hacking away when I get some free time :)

I think clang is intended to provide these features for Xcode.

As much as I care about elegance and simplicity, the C compiler is one tool where I can accept complexity. Especially for large instruction sets architectures like x86 I'm willing to let the compiler cast it's dark magic on my for-loops to give my 10% here and there. I don't think any project, much less the BSD kernel, can sacrifice even 10% in x86 performance for the sake of simpler compiler.

That said, the licensing with GCC sounds very complex and burdensome too. FTA:

>>> As with other parts of the GNU Project, GCC uses the GNU General Public License, although it has a special exception for any parts of the compiler that are embedded in the compiled output.

I am wondering if we end up with more than one c compiler. For the OS and base stuff, done with a compiler that is verifiable. For other more performance-demanding applications, something that compiles to faster code, but is not as verifiable.

We had that with assemblers. Back in the day, the Linux kernel was built with the x86 assembler from Minix (or a clone of it at least) and the rest of the system used GAS.

> That said, the licensing with GCC sounds very complex and burdensome too.

It's not really, it's just your standard GPL. The exception simply means that they don't try and make the GPL cover everything the compiler outputs and links into executables.

Too bad the FSF is in the process of obfuscating the GCC exception with some language about Eligible Compilation Processes in an attempt to regulate GCC plugins.

http://www.gnu.org/licenses/gcc-exception-3.1-faq.html

No, it's still simple: don't mix GCC with proprietary code. Code that gets output by GCC and inserted into other executables is still fine.

No, they're trying to say that using GCC's intermediary representations in your own code (both as output from GCC, and as input from GCC) counts as LINKING.

If the FSF wants to change or clarify restrictions on GCC, they should modify the GCC license. Putting restrictions on GCC in the license of the GCC runtime library seems unnecessarily confusing.

I love FOSS. But realistically speaking, the more complex a license is the more expensive it is to get sound legal advice on it.

I understand what the stipulations are supposed to mean: don't link with GPL unless you're going to release the source. But the legal language has a life of its own and it gets the final word. With all the stipulations around linking and compilation, there's got to be a lot of corner cases to consider and defend against, not an easy feat.

Granted FSF are not the most litigious guys around, but that doesn't make the license any less legally burdensome.

Ok, but 99.9% of people just use GCC to compile stuff. They don't care about linking to it, fiddling with intermediate representations, or anything like that. And the licensing is not "complex and burdensome" for people who just want to compile stuff. Indeed, it's far less "complex and burdensome" than, say, Microsoft's compiler, which is also used by a large number of people.

Good article. For C/C++ compilation I only know of GCC, Intel, Borland and Microsoft. And the last time I used Borland it ran on MSDOS. We could use more good compilers.

There are also Digital Mars, Watcom and lcc. And also SDCC.

Has anyone played with lcc - a retargetable c compiler?

http://www.cs.princeton.edu/software/lcc/

"GCC intentionally ties the front and back ends into the rest of the code quite closely, to avoid "semi-proprietary" forks."

You've gotta be kidding me...

That's a very suspicious statement.

GCC uses the GPL to avoid "semi-proprietary forks."

Check out this mail and the thread around it: http://gcc.gnu.org/ml/gcc/2002-02/msg01823.html They've argued this many times on the gcc list.

Reply on news.ycombinator.com