GCC Compiler Finally Supplanted by PCC? 546
Sunnz writes "The leaner, lighter, faster, and most importantly, BSD Licensed, Compiler PCC has been imported into OpenBSD's CVS and NetBSD's pkgsrc. The compiler is based on the original Portable C Compiler by S. C. Johnson, written in the late 70's. Even though much of the compiler has been rewritten, some of the basics still remain. It is currently not bug-free, but it compiles on x86 platform, and work is being done on it to take on GCC's job."
Kind of depends... (Score:5, Insightful)
Kind of depends on who you ask, doesn't it?
Re:"Nothing for you to see here" indeed... (Score:3, Insightful)
Answer (Score:4, Insightful)
No. Next question.
Interesting... (Score:5, Insightful)
Stupid waste of time (Score:4, Insightful)
Re:GNUless Linux (Score:3, Insightful)
But you're still stuck with using glibc if you want to be able to compile anything. You do have different libcs floating around, uclibc, etc; but they're all gnu and they're all meant for embedded market. I doubt you'd be able to recompile the linux kernel with any of them.
Re:"Nothing for you to see here" indeed... (Score:3, Insightful)
"The BSD folks would love to have a BSD-licensed drop-in replacement for GCC"
could somebody provide a reference to verify that "the BSD folks" do in fact have such a desire?
Thanks!
Re:Interesting... (Score:5, Insightful)
I don't know, I'm not a BSD user, but as much as RMS likes to claim that 'linux' is GNU/linux, maybe BSD users want their OS to be self reliant?
Would you like to compile Linux using a microsoft compiler?
Re:Interesting... (Score:5, Insightful)
Re:Interesting... (Score:3, Insightful)
3. they object to the restriction on their freedom?
Look, I am a Linux user and Hacker, but even I understand BSD need to have their code be free.
Increasingly extremeist? (Score:2, Insightful)
FSF's views have not changed over the years - they have remained consistent.
The reason they look "increasingly extremist" is because of other views on software freedom heading the other way, thus drawing an even greater contrast. That does not mean that the FSF views are the ones that are extreme...
If anything the FSF and RMS have shown themselves to be quite prescient in warning against dangers that have come to pass.
Re:Interesting... (Score:4, Insightful)
Reason 2) Competition
Reason 3) Choice
Reason 4) Tweak Stallman's nose
Yay for more compiler choices! (Score:2, Insightful)
Re:Increasingly extremeist? (Score:4, Insightful)
Re:Interesting... (Score:3, Insightful)
to me, it is the GPL that ensures that the *code* remains free, while the BSD license ensures that it is the *user* that remains free.
I really like both licenses, but they serve different purposes, and it highlights the priorities of the different groups.
Re:Interesting... (Score:3, Insightful)
He can't force people to change the name of Linux, it's just that people decided to go along with it on their own. The GNU/Linux thing was kind of retarded given that Linux distributions feature code from a lot of different licenses, and GNU is the only one that's mentioned?
Re:Interesting... (Score:4, Insightful)
The justification I've usually seen for that is that GNU is the single biggest "contributor", as it were, particularly with respect to gcc, the command tools, etc. More than just that, though, it could be argued that without GNU, Linux would just be a kernel, with no user space to run. Of course, it could equally be argued that without Linux, the GNU user space tools would just be a nice collection of tools with no OS to run on...
Re:Not for NetBSD for sure (Score:5, Insightful)
Actually, support for different architectures is one of the main reasons OpenBSD is looking at it. GCC has a habit of dropping architectures because 'nobody uses them,' which causes some OpenBSD (and NetBSD) ports to remain stuck with old versions of GCC. The x86 backend for PCC was written in three weeks by one person, so it seems reasonable to assume it should be possible to add support for the other required platforms relatively easily.
It's worth remembering that in BSD-land, things are divided into the base system and third party packages. The base system needs a C compiler that is capable of compiling the userland (which PCC already does for OpenBSD), is small, portable, and easy to audit. Packages have quite different requirements; they need support for more languages, etc. PCC is likely to replace GCC in the BSD base systems, but that doesn't mean that people won't install GCC or LLVM for compiling other things.
Re:The licence is just the top of the iceberg (Score:5, Insightful)
GCC's intermediate formats GIMPLE and GENERIC are based on a research compiler, not a deliberate perversion. There's no technical steps to stop reuse, and indeed it has been done - Sun distribute the GCC 4.0.4 front-end altered to use their own SPARC code generator as a back-end.
Re:Interesting... (Score:4, Insightful)
3. they object to the restriction on their freedom?
or
4. they like competition and choice, even if the "market leader" is pretty good.
or
5. they've learned that a monoculture isn't good for the ecology (even if the "market leader" is pretty good).
Re:Interesting... (Score:5, Insightful)
The real reason that Stallman wants this is that he early on correctly perceived that Linus is totally ideology agnostic, and so he wanted to put the idea of GNU/Linux out there so people would talk about the ideology. I don't think this is bad or anything. I think the ideology needs to be heard more widely.
It could also be argued that without the GNU project, Linus wouldn't have had a license ready to use for Linux, and I think that contribution by the GNU project weighs at least as much as all the userspace tools which someone would likely have eventually written anyway.
Re:Interesting... (Score:3, Insightful)
Not true, they run just fine on Solaris including Open Solaris which is OSS. In fact I MUCH prefer Solaris with the GNU tools loaded, the old SysV tools suck by comparison and I only use them for the rare script that breaks on the GNU tools (They are overall very good about preserving backward compatibility and man will almost always tell you when they don't). I know many of the stogy Solaris admin's don't like to load anything that didn't come on the first install disk, but if you have control of your environment and have linux experience it is really nice to load the GNU toolset.
Re:Does it crash less? (Score:4, Insightful)
while the person you're responding to *is* a troll, I guess it's worth pointing out that GCC and other highly optimizing compilers will "break" some apps that a simpler compiler won't break. Why?
Many optimizations rely on careful reading of the standard, and explicitly taking the liberties that the standard lets you take. For instance, the following loop terminates on a simple compiler, but becomes infinite on some optimizing compilers:
int i = 1;
while (i > 0)
. . . i = i * 2;
The ANSI C standard states specifically that signed integer overflow behavior is implementation defined. If you were expecting 'i' to go negative after 30 iterations, and for that to terminate the loop, you could be in for a nasty surprise.
Suppose an application relied on this behavior, and now it misbehaves when compiled with GCC. Did GCC "break" that application? In some sense, yes: The app functions correctly with compiler (a) but not with compiler (b), so the app must be compiled with compiler (a). The breakage, however, happened because the application its not strictly conforming. It uses compiler dependent semantics, and that's hardly GCC's fault.
Simpler compilers also don't reorder code as much, and don't optimize away as much "dead code." Stuff that really should have memory barriers, explicit synchronization and perhaps the volatile keyword applied to them run just fine without all those things when compiled with a simple compiler and run on a scalar, in-order CPU. The source code is also easier to read, because in the end the semantics are much more restricted--meaning the compiled output more closely resembles the source input. Give that code to a highly optimizing compiler, though, and run it on a super-scalar, out-of-order machine, and it'll break left, right and center. Is it the compiler's fault? Is it the CPU's fault? It's really the gap between the semantics the programmer thought he had (and happened to have in the simpler environment), and what C actually guarantees.
Simpler compilers implement simpler semantics that are easier to understand, but only because they're compiling a very restricted form of C that offers way more implicit guarantees than the C standard actually does. Personally, unless that's made explicit (and therefore truly guaranteed forevermore by the compiler), I suspect it's actually a recipe for disaster. If nothing else, it could lead to code that's significantly harder to move to different platforms, since it'll start to rely on these simpler, "easier" semantics. Of course, then again, super-scalar out-of-order CPUs still strip a bunch of that away, so who knows, it might not be that bad.
--JoeRe:Interesting... (Score:3, Insightful)
GNU tools ran fine on other OSes long before Linux became so popular, including Solaris (and SunOS before it), AIX, HP/UX, IRIX, NEXTSTEP, Ultrix, and so on.
Re:Interesting... (Score:4, Insightful)
I can understand some applications having closed source licenses...but a compiler is a means, not an end...it really just seems painful.
Does speed of compilation really matter to pros? (Score:2, Insightful)
And frankly, slower compilers mean secksier hardware requirements for workstations.. ("Yes, GCC4 is slow, that's why I need that dual quad-core Xeon with 4GB RAM!!")
Meh.
Re:Interesting... (Score:5, Insightful)
I am the GPP, incidentally, and while I'm pleased I got modded up, I certainly wasn't going for funny :). I'm sorry, but C is just a poor choice for ensuring correctness.
First of all, open up your copy of the C standard (any of them will do) and grep for the phrase "undefined behaviour". C was standardized in a time when everyone and their dog had their own C compiler. Each C compiler did things in a different way, often in contradictory ways. The C standard came along and said "hey, you know what? You're ALL right". I'm being facetious, and the C standard has done a great job in promoting C, but the C standard has really not evolved very far in terms of guaranteeing semantics.
I don't mean to bring this up to say that "you can't write correct code" in C or such nonsense. Obviously it's easy with good habits (I recommend comp.lang.c as the best place to pick up these habits) to write conforming and well-defined code. But, if you're trying to verify code that's already been written, either by hand or via some automated tool like a static analyzer, it is painful.
The second problem with C is that it allows a lot of features that make verification of semantics difficult. Pointer aliasing, global variables (even "extern" global variables!!), etc. make static analysis dreadful. If you want to perform static analysis properly on C programs, it's hard to get around whole-program analysis, which is why no one uses static analysis with C code :). Seriously, what does C have beyond lint? How many people even use lint? It's not very useful.
Of course static analysis is not the end-all be-all of ensuring correct code. There's good coding habits and testing and profiling and whatnot too. But, I would argue that whatever effort can be put into verifying C code can be better put into code in other languages. The semantics of C are sometimes loosely defined, and very often far-reaching, preventing the use of modular reasoning. Whole-program analysis is not your friend.
What would be really cool is to see from someone like the OpenBSD crowd, if they're so keen on C, develop some verification tools that maybe only work on a very, very restricted subset of C. Any code which does not conform to this restricted "more easily verifiable" subset of C in the core OS would be rejected. I don't know how practical it would be, but it would be cool to see :). I mean as an academic, obviously I think we should all be using Z [wikipedia.org], but I understand this doesn't make good sense in a lot of real-world projects. But you want to get serious about correctness, don't pussy foot around: get serious about correctness.
Re:Interesting... (Score:3, Insightful)
Re:Interesting... (Score:5, Insightful)
Better idea, let's just get history correct.
Ok, true enough.
Sure, and I've almost created a free engery device ... I've done everything apart from this one bit that creates energy for free. Also, GNU did not "create" everything else apart from the kernel ... they created some pieces and were doing the distribution work, so other people "donated" their work.
True enough.
Not even close to true, Linux has only ever distributed the kernel ... other people combined it and called the whole things like "Red Hat Linux" or "Slackware Linux", GNU should/could have done this but had not bothered to do the work to make a usable distribution (as more than a collection of tarballs) and were happily ignoring Linux and telling everyone else to ignore it and use GNU-Hurd when it would be ready "any time now". This was pretty obvious naming at the time, we didn't call Solaris "GNU/Solaris" when we installed GCC, GNU-tar etc. on it.
They got a huge amount of credit, for the work they did. They just didn't get their name in lights ... because they refused to do the work required for that. Then they complained and wanted more recognition than anyone else got who'd done the same amount of work as they had (like Perl or Xorg etc.) ... this created a "slight" backlash by people who actually know what happened.
Re:Interesting... (Score:3, Insightful)
I don't think it's meant as FUD. Actually the idea that the code itself has been emancipated, so that no one can bind it or its children with the chains of ownership ever again, is quite an attractive and appealing idea.* Stallman was a bloody genius to come up with such a wild abstraction. He's freed the slaves all over again, it's just that these slaves are not human.**
However, while this philosophy maximizes the freedom of the code itself, it does so at some cost to other interests. One cannot bind the software with the chains of ownership again - that's the whole point - which is a bit of a problem if one wishes to write code that can be used by any human for any purpose even if it means some of the code's children can be chained up again by some bloody-minded capitalist while others remain free. The BSD license maximizes the freedom of people, while not providing complete protection from slavery for all of the code's children.
Both licenses attempt to maximize freedom, but they do so in different ways and for different interests; to secure those different freedoms they must make different tradeoffs.
[*: When I say this I definitely do not mean to spread Fear, Uncertainty, or Doubt. It's meant as a compliment... although there are of course some who will view Stallman's grand idea as just bizarre philosophical wanking.]
[**: And if you think this debate is interesting, just wait until the GPL philosophy meets seemingly self-aware robots! See also Asimov's book "I, Robot".]
Re:Interesting... (Score:3, Insightful)
At what point are you forced to grant credit? Shall we call it KDE/QT/GNU/Linux?
No it couldn't. The comparable BSD tools have been around longer than the Linux kernel.
Before Linux, it was pretty common to install several of the GNU tools on the closed-source Unix systems of the day. Problems with the GNU tools on Minix was in fact the motivation for creating Linux. Today, everyone that has to use a Solaris system for any length of time installs the GNU tools and tries very hard to forget that the Solaris crap even exists. Bash, if nothing else, is a common install on any Unix system (even though OpenBSD's branch of pdksh, and ksh93 are actually better shells, IMO).
Re:Interesting... (Score:2, Insightful)
Also why should they not be allowed to make a new compiler, Toyota started to make cars long after Ford made theirs - even though - eeh - Ford already made cars that did all the things that the Toyota cars did.
What license doesn't ensure , oh, let me turn it around - what license ensures that committed code makes it in? The manager of a project allows or disallows for code to be committed, not the license.
A compiler is an application, an application that compiles source code.
A lot of people in the bsd developer teams are tired of gcc becomming more and more complex and becoming slower and slower at compiling. This might indicate why some are trying to find alternatives.
Re:Interesting... (Score:3, Insightful)
In fact, Fords do something Toyotas don't do, namely explode.
Although GCC doesn't do that (that I know of), I see no problem with having an alternative. There are competing applications for everything else, from desktops (Gnome/KDE) to kernels (Linux/BSD), so why not compilers?
Re:not every architecture (Score:2, Insightful)
Re:Interesting... (Score:3, Insightful)
It's not like a C compiler is a very difficult thing to write. GCC is much more than than just a C compiler. But if a C compiler is all you need...maybe GCC is overkill.
Re:"Nothing for you to see here" indeed... (Score:3, Insightful)
Re:"Nothing for you to see here" indeed... (Score:3, Insightful)
I do like the fact that we will (hopefully) have 2 good compilers, but people aren't going to simply start licensing things under BSD just because of GPLv3, they will just keep using GPLv2 because they were using GPL for a reason.
Pure ISO C99 has limitations when writing a kernel (Score:5, Insightful)
Re:Interesting... (Score:3, Insightful)
Re:Your are misinformed (Score:3, Insightful)
The same rule applies to copyright notices. You are not allowed to modify the copyright notice on a work even though it doesn't explicitly say such modifications are forbidden. The BSD license reminds recipients that they have to keep the copyright intact, but this is done as a courtesy and is not required.
As for your Wikipedia quote, I already gave a detailed explanation of how BSD licensed code can be distributed along with code that has a more restrictive license because this might be what has caused the widespread misunderstanding that you are still suffering from.
The rule is trivially simple: unless you are given explicit permission from the original author, you can't change the license or copyright notice on someone else's work. Period.
Re:"Nothing for you to see here" indeed... (Score:3, Insightful)
Well, no. On the other hand, the post to which the GP was responding seems to be implying that a GPLv3 GCC will infect its output, on account of its being "poisonous and viral". Either that, or it's a screaming non-sequiteur and totally off topic. You can't blame the GP for giving a poster the benefit of the doubt.
What a strange thing to say! I most certainly does matter if a compiler imposes its licencing terms on any programs it compiles. This would be a major show stopper for all sorts of deployment scenarios.
Happily, GCC has never imposed such restrictions. You could argue that the point is moot in this case, but it's hardly unimportant.
I can't see why. It's not like the FSF will (or could) discontinue the GPLv2. If it was a good licence before v3 (and it was) then GPLv2 is still a good licence now.
Re:Does it crash less? (Score:3, Insightful)
It is extremely difficult and next to pointless to write code that is strictly conforming. It is in fact quite useful, for instance, to use unions to re-interpret bit patterns. (Note that "portable" is something rather different than "strictly conforming," or even "conforming." Many non-conforming programs are still highly portable because of commonalities among implementations.)
For example, suppose you want to bit-reverse an entire array in memory. That is, bit 0 of the first element in the array swaps locations with bit N-1 of the last element of the array, bit 1 swaps locations with bit N-2, etc., all the way down to the middle of the array. How would you implement that as a strictly conforming ANSI C program? It turns out to be rather difficult to do correctly. (Why would you want to? Well, it's a handy way to flip bitmaps for one thing.)
First, you have to know how many bits are in each unsigned char. There could be from 8 to who-knows-how-many bits in an unsigned char. (Yes, 256-bit unsigned char are legal in ANSI C, as long as there's at least as many bits in a short int, int, long int and long long int.) So, you can't rely on any fast, cute implementations such as this ever-popular word-reversal routine:
That code is implementation defined. It cannot be part of a strictly conforming program. It can be part of a conforming program, though it only works as expected on machines whose unsigned int is 32 bits. (That happens to be over 90% of the PCs and *NIX boxes people work with these days, but that wasn't true as recently as 10 years ago.)
What about other undefined things? Well, sometimes an implementation defines them usefully. For example, consider this bit of code:
This is useful code. Chances are nearly every compiler you meet (at least, which offers 32-bit ints) will handle this correctly and tell you the endianness of the machine. That means it's reasonably portable. It also happens to be quite undefined.
Sure, it fails miserably on oddball machines with non-standard word sizes, but most programs only care to be portable amongst the vast majority of machines that have 8-bit char, 16-bit short, 32-bit int. (This is part of the reason why LP64 machines are more popular than ILP64 machines.)
In general, compilers implement a superset of the standard by providing reasonable semantics to expressions that the standard leaves undefined. For instance, on most compilers, signed arithmetic wraps around the same as unsigned arithmetic, and the values you get are exactly what you'd expect from 2s complement arithmetic, despite the fact that the standard leaves those results undefined. Heck, until the adoption of C9x, C++ style comments were not technically legal in C programs, but most compilers accepted them.
--Joe