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."
I notice that TFS doesn't say that anyone is actually able to compile anything (other than PCC) with it. The BSD folks would love to have a BSD-licensed drop-in replacement for GCC; but it doesn't sound like this is it. Not yet at least.
./build.sh or whatever).
Wake me up when you're able to use PCC instead of GCC to do a 'make world' (or
Kind of depends on who you ask, doesn't it?
OK, so it compiles C on x86. What do I use when I want to compile objective C on my microwave?
Someone relicense it under the GPL!
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
call me when pcc does something useful, like, say, working.
pcc will take YEARS to get the functionality and optimizations that gcc has. Even if it compiles slowly and sometimes generates dumb code.
Either way, they'd much, much better off if they imported LLVM and redirected their compiler brain power to clang.
PCC is interesting, but it's based on technology from the 70's, doesn't support a lot of interesting architectures, and has no optimizer to speak of.
If you're interested in advanced compiler technology, check out LLVM, which is an ground up redesign of an optimizer and retargettable code generator. LLVM supports interprocedural cross-file optimizations, can be used for jit compilation (or not, at your choice) and has many other capabilities. The LLVM optimizer/code generator can already beat the performance of GCC compiled code in many cases, sometimes substantially.
For front-ends, LLVM supports two major ones for C family of languages: 1) llvm-gcc, which uses the GCC front-end to compile C/C++/ObjC code. This gives LLVM full compatibility with a broad range of crazy GNU extensions as well as full support for C++ and ObjC. 2) clang, which is a ground-up rewrite of a C/ObjC frontend (C++ will come later) that provides many advantages over GCC, including dramatically faster compilation and better warning/error information.
While LLVM is technologically ahead of both PCC and GCC, the biggest thing it has going is both size of community and the commercial contributors that are sponsoring work on the project.
-Chris
"So, really, there's no point in duplicating effort on a BSD lisenced compiler. Correct me if I'm wrong."
From the discussion of TFA:
The licence is just the top of the iceberg
Let me get this straight. A compiler that has been production-quality for over 15 years, compiles everything on every architecture, and has been continuously improved every minute of its existence needs to be replaced by ... Son of pcc? Because of a license?
Sure, I prefer BSD-style licenses, and so do some other people, but what drives gcc development is the GNU license. I think I'll stick to the compiler that's debugged. Oh, that's right, I forgot, it comes with a debugger too. If you like that sort of thing.
The reason they look increasingly extremist is because the FSF tends to make up policies and rules which bind GCC development in order to avoid the theoretical risk of making GPL violations easier. As compiler technology advances these restrictions have become increasingly burdensome, in particular, several of the technical advantages of LLVM are things the GCC team would have liked to do but RMS nixed because it would have made it too easy to circumvent the license.
- Must compile C code (GCC does this).
- Must support all of the platforms OpenBSD targets (GCC has a habit of dropping support for various platforms).
- Must be easy to add new backends for new architectures (GCC makes this really hard).
- Must be easy to audit for security (GCC is a tangled mess).
Maybe a few I've missed. GCC is like Linux; it's a fairly good solution for a lot of problems, but it's rarely the best solution for any given problem. PCC is a better fit for the needs of the OpenBSD base system.I am TheRaven on Soylent News
The biggest reason for the new compiler (despite the jackass article submitter's position) is that GCC does *NOT* support every architecture. GCC drops architectures frequently as the core contributors lose interest, which hurts OSes like NetBSD that try to support more than the mainstream architectures. NetBSD relies on a combination of GCC 2, 3, and 4 to compile the OS on all of the architectures it supports.
The idea with PCC is not that it will be BSD licensed (nobody really gives a fuck what license the compiler is under), but that it will be supported directly by the BSD community, including the NetBSD hackers who have their bazillion architectures to support.
First: PCC has not YET supplanted GCC. The BSDs are hoping it will in the future.
Second: The biggest attraction of PCC is NOT the license. The article submitter who stated otherwise is a jackass.
Third: There are techical reasons why GCC is actaully unusable by some BSDs, such as NetBSD, which aims to support many architectures that GCC has dropped. NetBSD uses a combination of GCC 2, 3, and 4 to compile all of its different architectures. The NetBSD developers would rather have a single compiler that handles them all. Obviously PCC is nowhere near that level yet, of course.
Fourth: GCC politics are a pain in the ass for many BSD developers who just want to submit patches to a compiler without the overhead of GNU's policies and GCC's management.
Fifth: GCC produces crappy code more often than anyone would like. GCC bugs are far from unheard of, performance of generated code is often unpredictable between releases, and in many less commonly used architectures or sources GCC will produce incorrect code. Yes, these cases are very rare, but the BSD folks have hit the problem often enough for it to be a concern. PCC, being simpler and less bloated with cruft from multiple rewrites of the internals will hopefully produce correct and predictable code more often than GCC.
Sixth: PCC actually works today. It can compile most of the NetBSD userspace, as I recall, and the kernel will be ready to roll soon after some inline assembler problems are fixed. This isn't some theoretical hacky project - it works right now. It's not ready to replace GCC just yet, by any means, but it's a lot more than some Slashdotters seem to think it is.
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!
Think about it. Getting a new compiler into free UNIX and the open source community is going to be as hard as getting a new platform on the desktop to compete with Windows. And for similar reasons.
You're not going to supplant GCC until you get all the code that depends on GCC-specific features modified to be standard portable C. That's a barrier to entry as steep as Microsoft's application barrier to entry. Now it's not as bad as it was in the early '90s when GCC was sprouting new C extensions everywhere (like the ability to have declarations not at the start of blocks, or the ability to leave the second element out of the trinary conditional operator, or things like alloca), and a lot of those features have now become common and even standardized (and others, like the shortcut trinary, have been deprecated). But it's not as easy as just having a good compiler, or even a good language translating ecosystem like Tendra... the playing field is anything but level.