OSNews

There already is PCC. I think its the design of LLVM that makes it more newsworthy rather than being a possible replacement for GCC in BSD systems. If you haven't look at it more closely I'd recommend it.

..or we could look at how LLVM *compliments* GCC, Or we could focus on how open-source compilers rival *commercial proprietary* compilers, or we could look at how for 20 years that a project started by Richard Stillman has been an intregal component of BSD kernel distributions, and is set to continue for some time.

oh I forgot its much better to have another smack down over the benefits of copyleft vs permissive licenses.

I agree with your comment but I was talking about "CLANG" not the "LLVM-GCC" part.

* added a missing word.

Edited 2007-09-30 02:06

"or we could look at how for 20 years that a project started by Richard Stillman has been an intregal component of BSD kernel distributions"

There's not a *Single* line of GNU/GPL in ANY of the *BSD kernels!
GCC simply *Compiles* the BSD sources and makes binary code.

Thanks.

BSD kernel distributions. In other words, the various BSD OSes, which (as you mention) use GCC.

No thank you. You misread me if you *re-read the quote* you will see that it says "BSD kernel distributions" which all contain GCC and Gnome and ... well you get my point, and all are *compiled* with GCC.

I make the point with no smack down. I use a kernel that Thom regularly advertised as *using* code from the BSD kernels, Every Linux based Distribution comes with X(ok not quite BSD).

Although I thank you again for *stressing* a different but supporting point as to why this should not be used in any smack down on different kernel licenses.

I personally think there is more to celebrate with successful open source applications that *compete* with proprietary ones like that of Firefox(under the Mozilla License) or when *binary proprietary blobs* are finally removed that damage all open platforms like that of Gnash by the FSF.

...Its not that I don't care about the license I think their are better points to be made about LLVM as being a replacement for GCC(it isn't check the slides) on BSD distributions. In fact if you click the link and look at the slides you will actually see quite a few *real* advantages to both clang and LLVM over their selected parts of GCC both technical *and* even some related to the license...and some disadvantages.

Edited 2007-09-30 02:45

"No thank you. You misread me if you *re-read the quote* you will see that it says "BSD kernel distributions" which all contain GCC and Gnome"

Actually, Gnome is not part of FreeBSD core, it is part of the ports collection. I cannot comment on the other BSDs, But with FreeBSD it is not part of the distribution. Similar to how Debian and Ubuntu have non-free repositories. It's easy to install, but not installed by default.

I understand where you're coming from but nobody ever said that there's GPL'd code in BSD. In fact, if there was any GPL'd code used in say the NetBSD kernel, it would no longer be BSD.

On the other hand, it is with the help of a fellow opnsource project, namely the GNU C compiler, that other opensource projects, in this case the BSDs, can build they're systems without having to buy expensive compilers. As far as I'm concerned, that's a win-win situation.

I'm happy to hear that there are compilers being release that are more in line with the BSD philosophy, but that hardly means that GCC should not be valued for it's prior usefulness.

Pardon me, but it is time to stop propagating this absurd myth.

If there were any GPL code in the NetBSD code, the kernel would still be BSD, but it would be infringing the GPL license until that GPL code was excised. Legal measures could be taken, fines may apply, lawyers would get rich(er), but the BSD license would continue to apply to BSD-licensed code just the same.

Mate, its not that.

Talk to Sun, Apple and many other vendors who have tried to get patches merged which fix bone head stupid bugs - GCC maintainers refuse to merge it. There isn't a thing they can do but either absorb the extra costs of manually patching and compiling or simply stop providing GCC for their platforms - then we all suffer because of it.

GCC maintainers don't want to accept there could be some issues that need to be addresed; gcc to them is like a sacred cow; perish the thought that there are bugs and patches might get submitted by those out side the "Illuminati" and actually help develop GCC.

I just hope that if GCC developers keep messing around companies, the likes of Sun turn around and throw their weight behind LLVM.

Talk to Sun, Apple and many other vendors who have tried to get patches merged which fix bone head stupid bugs - GCC maintainers refuse to merge it.

Can you provide an example of this happening?

Look through Sun and Apple mailing lists.

Read through the comments on the Undeadly.org story regarding integrating PCC into OpenBSD. There are a handful of very long posts on there that go into lots of detail on patches that people have made that have been ignored. Patches that fix issues and long-standing bugs in GCC, patches that fix regressions. And patches that have been summarily ignored.

I'd post the link to the story, but for some reason, we can't access undeadly.org from work (most likely the provincial network folks are blocking it).

It is my opinion that there should be at least two major FOSS players (with a strong commitment to standards, interoperability, and compatibility) in any given area. GCC needs some competition. Sure, multiple projects results in a division of resources, and some people don't like that. But look how dividing the resources between XFree86 and Xorg worked out for us.

I agree, GCC really needs some competition. At the worst, a few resources are wasted but I think history has shown that it almost always leads to better products.

Yeah. There's ICC (Intel's compiler) and the Sun Studio Compiler series. Both of these are better for their preferred targets (x86 or SPARC) than the MS compiler or GCC. The MS compiler until recently produced slightly better code than GCC. By now it's probably neck and neck, but MSFT is doing a pretty major revision of their compiler backend right now that may (or may not) bring it back into the lead.

A real measure of how good a group is at producing compilers is what they do with Itanium. Itanium is heavily-dependent on the compiler to generate explicitly parallel code, so compiler quality matters a lot. The first compiler for such EPIC processors was the MultiFlow compiler (currently owned by Reservoir Labs and called Blackbird).

I'm not sure that codegen in the compiler is going to improve a whole lot in the future. The next direction will likely be theorem-proving compilers that output information about the purpose of the code they're generating and verify the type-safety, thread-safety, and other properties of the code. You can see a rudimentary form of this already with the PreFAST /analyze extensions in MS's compilers. If LLVM can bring this to open-source, then it will be a worthwhile replacement for GCC (and a good way to unshackle open-source from the FSF).

"If LLVM can bring this to open-source, then it will be a worthwhile replacement for GCC (and a good way to unshackle open-source from the FSF)."

I find this comment from a user like yourself a *strong* advocate of the Microsoft *proprietary* platform, somewhat ironic. I am pleased that you have again reinforced the fact that Richard Stallman created GCC and FSF have steered the project for *20 years*, but I suspect it is another off-topic slight against the FSF.

I would love to see justification as to why a project that involves mutual collaboration between *companies* is better in whole or in part controlled by a single company instead of an *organization*, especially since by your own point GCC is a cross-platform compiler unlike the proprietary one you advocate which is unavailable to any other platform but Microsoft's own, yet your advocating control of the compiler by companies who have an interest in only *their* platform.

Edited 2007-09-30 15:39

I believe that allowing proprietary compiler backends can allow hardware firms to produce new chips with a smaller investment. GCC could have been the compiler that would plug into chip-specific codegen modules, but it was specifically designed to disallow this, because the FSF people are so small-minded and ungenerous (hint: even if a commercial company takes your code and tries to sell it to people, you haven't lost the code you've written, and with sufficient patent-lefting, you can always catch up to their improvements).

LLVM is designed in a better way to allow plugins to be made. It could become the backbone around which people bring new kinds of processors with differring codegen requirements to market. Even without that, as sbergman says, competiton is always a good thing.

"I believe that allowing proprietary compiler backends can allow hardware firms to produce new chips with a smaller investment."

I think the cost of writing compiler backends would be insignificant compared to the cost of developing new chips. Do you have reasons to believe the contrary?

"I believe that allowing proprietary compiler backends can allow hardware firms to produce new chips with a smaller investment. GCC could have been the compiler that would plug into chip-specific codegen modules, but it was specifically designed to disallow this, because the FSF people are so small-minded and ungenerous (hint: even if a commercial company takes your code and tries to sell it to people, you haven't lost the code you've written, and with sufficient patent-lefting, you can always catch up to their improvements)."

I'm shocked and appalled at this comment, do you seriously believe in these words. You openly(sic) advocate Vista. As OS that abuses smaller companies ability to compete in many areas from browser; chat; media center; media player; parental controls; virus protection; firewall thats ignoring all the proprietary formats; protocols etc that involve. Thats ignoring the costs of smaller firms wanting to bundle windows, marketing pressure to remove alternatives to their own products being bundled with OEMS, or small OEMS not being able to compete with large ones...or even to hardware producers the cost and complexity of conforming with Vista's overreaching DRM. I could go on. I wouldn't label it "small-minded and ungenerous" I won't even label it as business(sic) Its *criminal*.

Richard Stallman *wrote* GCC 20 years ago and it was faster than *commercial proprietary compilers* costing thousands of pounds. What did this "small-minded and ungenerous" individual do he open-sourced it and put it under a license that ensures it will *always* be open for *everyone*. Anyone with the means to help out with GCC can do so...It can even be forked. I can even use it as the basis, of my own compiler...or I can study it to see how a compiler works...and well I just think you are being a little silly.

I'm glad that your focusing on sbergman usual anti-Linux propaganda, competition is good. Its a shame this only applies to software you don't use/advocate I say advocate I mean attack individuals who have *already* created competition in the compiler marker with an open-source alternative.

The sad thing is I wished you really understood the phrase "competiton is always a good thing" then perhaps you wouldn't spend you time defending every monopolistic abuse the Microsoft do. Then and only then would your computing experience be on par with mine.

The great thing about open source software is that anyone can patch the software so that other compilers can compile it. If other compilers start gaining users I'm sure that will happen, but for now I think it is understandable given almost everyone uses GCC. I know that the KDE project is currently fixing it's software to work with Sun Studio since they're officially supporting Solaris with KDE4.

Edited 2007-09-30 04:17

If the Linux kernel developers had any interest in supporting any compilers other than GCC, GCC-specific code hadn't been accepted into the code repository in the first place.

It can also lead gcc users into bad habbits. I taught myself C using gcc, whenever I had a problem I'd search usenet and the web and often find solutions often posted by people who also used gcc. As such things where fine and I learned many things and started getting a good grasp of C (or so I thought).

Then, later, I ended up writing C code at a place that didn't use gcc, but a different and much stricter compiler. All of sudden many of the things that had been worked fine for me all along gave a bunch of strange compiler errors. So I ended up having to re-learn much about C which I thought I already knew.

So use '-Wall -Werror -c99 -pedantic'. You *can* make GCC stricter.

I know now that I can, but it isn't the default and when I was learning C no tutorial or book told me to do so, or exlicitly mentioned that if I didn't do that I wouldn't be learning 'correct' C but a highly unstandard gnu C.

I'm not really blaming the gcc team as such though, since I actually prefer the non-standard gnu C because it makes many things easier. It's just that one has to keep in mind that it is non standard and perhaps things could be done to make that more clear.

"What is the benefit of LLVM for C/C++ developers?"

It's dead simple. LLVM generates faster code (better optimization) in less time (better optimization architecture).

There are interfaces to JIT and optimization passes, but they aren't interesting unless you are a compiler developer.

An analog question would be: What benefits has the JVM for a Java developer?

In the same way one can natively compile Java programs one can use C/C++ with a VM.

It means it can use the "classic" optimizations (at the source level), link-time optimizations, and profile-guided optimizations (at run-time).

Clang is an interesting project but it probably has problems in some cases. Translation from C++ to ObjC is not as trivial as it seems. ObjC is a superset of C but C++ is not really. Going from C to both languages is trivial but going back presents a challenge.

nobody is trying to translate from c++ to objc. clang "translates" c++, objc and c for lvvm. maybe you think of objc++, which allowes mixing of objc and c++?

http://en.wikipedia.org/wiki/Objective-C#Objective-C.2B.2B

I suspect it would take a little bit more than one ebuild: almost certainly a new profile would be needed, new eclasses, not to mention rewrites of all the gcc and autotools wrappers Portage uses. Then of course they'd need to craft their own install medium so they can bootstrap the whole system with LLVM. And that's ignoring the issue mentioned above with the kernel and other key bits of infrastructure being gcc-dependent...

Ricers may enjoy tweaking but I doubt there are many willing to take on a job of that scale. Not saying the Gentoo team themselves might not try it -- they've always been up for a challenge, just look at the FreeBSD and MacOS ports -- but don't expect it to happen in a hurry.

Not nessecarily. LLVM has a front end that is based on gcc and works just like it, except that it uses LLVM as the back end. So theoretically it would be as easy as replacing gcc with LLVM/gcc. Of course a lot of stuff would probably not build but it wont be as difficult as switching to, for example, icc or another completely different compiler.

The reason it is used so little in practice is that it is relatively new technology. I expect to see a growing number of usages in the future.

Ask that question again, after XCode 3.0 and Leopard are released.

I don't know about other projects (I guess if a new project was started right now that needed an execution engine, they should consider llvm), but I can tell you why Mono doesn't use llvm.

First when Mono started writing its own JIT llvm was very immature (we're talking about 6 years ago): it is now mature as a compiler, but still very much unproven as a JIT.

Second, Mono supports more architectures than llvm and has done so for several years, so unless llvm catches on, we're not going to lose supported architectures.

Third, llvm is HUGE: just the x86 specific code (in an optimized build) is as large as the whole Mono runtime (which includes 500 KB of locale data). This makes it unsuitable for the environments where Mono is already used, like embedded devices. The bloat factor translates also to runtime memory usage and JIT compilation speed. While llvm is definitely faster than gcc, that doesn't say anything when you need to JIT code as fast as possible (and when you need to load 2 MB of code in the cache just to jit a single method it starts to drag everything down, not including the data structures needed by the JIT process itself).

Then there are various other reasons, like the tight control the Mono runtime needs on some generated code (the llvm exception handling mechanisms are inadequate for a full featured runtime like Mono), the integration with the GC (llvm has some embryonal support for this),
the need to control runtime behaviour precisely vs memory and stack usage (the amount of stack space the JIT can use is small and it needs to be deterministically fixed: using llvm here would need having a black box with not control on it), some low level details that I explained some time ago in a posting to lamba the ultimate that you might want to check.

Overall, for Mono to switch to llvm, a lot of work would be needed: implementing all the missing features in llvm, de-bloating it, writing the ports for the missing architectures and finally writing the backend to target llvm inside Mono. This is easily 2 years of work just to get something working correctly (and some things would be still suboptimal, it's hard to debloat the x86 support code from 1.5MB as it is in llvm to the 100KB it is in Mono). In the same amount of time we can add more architectures to the supported list or write more optimizations that are suitable for a JIT compiler.

The reason that Python and Ruby don't use LLVM currently is that their runtime requires additional capabilities that LLVM doesn't supply as a low-level platform. See http://hlvm.org/ for details about its sister project High-Level Virtual Machine.

Agree 110%. The work by all the folks is monumental.