Slashdot Mirror
GCC Compiler Finally Supplanted by PCC?
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 on who you ask, doesn't it?
...Wake me up when you're able to use PCC instead of GCC to do a 'make bzImage'
GCC Compiler Finally Supplanted by PCC?
No. Next question.
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
I really don't see any point in implementing a new C compiler under the BSD lisence. There's no reason to duplicate effort: it's not like the compiled binaries would be under the GPL. And any GPL libraries you link to, you wouldn't need to distribute (thus avoiding the GPL). So, really, there's no point in duplicating effort on a BSD lisenced compiler. Correct me if I'm wrong.
Seriously. Let's duplicate the wheel twice: once for GPL, once for BSD, and then bicker amongst ourselves. Stuff like this stands in the way of actual progress being made. Neither side is right, I don't have a solution, but this is just dumb.
twitter.com/gravitronic
Not really; you already have the sun and intel compilers for Linux (I've been told that the intel compiler has even been tweaked so you can build a bzImage with it).
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.
With respect to
"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!
FSF's increasingly extremist political views
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Even if a compiler generates miserably inefficient code, it is valuable if the code is correct. It ia a valuable tool to use for the verification of other compilers. It can also be used as part of a compiler bootstrapping process. Since its code size is probably a small fraction of GCC's, it may make a better teaching tool. If people are actually going to use it, given that it must coexist in a world with much more mature compilers, it will itself probably become much more mature in a relatively short period of time. GCC currently has no competitors in the free realm and has suffered from neglect in the past. A little competition may keep the developers on their toes and prevent another egcs.
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.
I am TheRaven on Soylent News
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.
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.
--JoeProgram Intellivision!
Seriously, if you're writing code for a living, especially performance-critical code, isn't hardware/platform optimization for the end-use binary far more important than speed of compilation? Particularly if that binary gets blown out to hundreds or (of?) thousands of boxes. If I had to choose between a slow, but hand-tuned GCC for my platform or a quick other compiler that made correct but mediocre-performing (no SSE?/3DNow/VMX/VIS or whatever) binary code, I'd say GCC no contest.
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.
If they are interested in these architectures, they should help GCC folks maintain them instead of resurrecting obsolete compilers.
Please explain how the license for GCC affects code compiled by it.
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
What will actually happen is GCC will get forked at GPLv2, if the majority of people are behind the v2 fork the v3 version will become irrelevant.
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.
The license doesn't explicitly say you can't modify it because it goes without saying that you are not allowed to modify it. If the default was for licenses to be freely modifyable by recipients then they would all be worthless. Also, it would be asinine for the default to be that you can freely modify the license because then every single license would have to have a standard clause that says you can't modify it.
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.
We don't see the world as it is, we see it as we are.
-- Anais Nin
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.
Don't let THEM immanentize the Eschaton!
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.
--JoeProgram Intellivision!