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
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
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.
It has less to do with the license and more to do with GCC's increasingly spotty support for some of the hardware platforms that NetBSD and OpenBSD run on. That and GCC internals are a maintenance nightmare, and its development process is getting even less commmunity-driven than it was before (which was never that much). Asking for a new compiler warning might take anywhere from a day to years just to get a response. The license is definitely gravy though.
The BSD license that PCC is under, I understand, is actually a problem even to the BSD folks: PCC is actually extremely old (it was originally written for the PDP11!) and apparently it still carries the advertising clause.
I believe it was de Raadt that once mentioned he'd prefer a non-optimizing compiler that produced simple, bullet-proof, bug-free code, i.e., in terms of the OS and its base tools, he prefers correct to fast.
Well that explains a lot. And here I was thinking that all modern compilers were designed correctly with a front-end and back-end. So much for academics.
Actually, the post you're replying to is total bollocks. GCC has had a clear divide between front and back end (not to mention a source-language independent middle layer for performing optimizations) since I first looked at it in about 1996. Each layer is hideously complex, but they are all there.
Auctually if I could write in C as well as him, I would do so more often. The problem is not him writing in C, its other people writing in C that are not as good as him. Do to the scope of his work, him writing in C does not lead to more bad C being written. So I'm auctually thankful he is coding in C.
That being said, he should encourage lesser programmers (including myself) to specifically not code in C.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
Far too true, however for working with flexible or hazy requirements or looking to make code that is fast, C is very hard to beat. Also, just because this is true today, doesn't make it something that will be true forever.
F... "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.Once again, totally on the money. The standards group was too concerned to fix things like bitfields to make them useful, or standardize the method of determining the size of an "int". I think the standard evolved more to making the compiler writers happy than to make any real effort at fixing vague semantics that are quite prevalent and cause any number of problems.
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.This is so true that it is painful to hear! I worked a couple of years with a tool to analyze code for customers. The variability in the compilers, environments, implementation details, user hacks, or compiler switches that affect code is dizzying. Has anyone else enjoyed the declaration "char myvar[0]" construct?
However, before you condemn all of the analysis tools, check out tools that perform "semantic analysis" (that what it was called when I was there) of C code. You may be pleasantly surprised. But it is still a challenge to wholly analyze any project. C++ is hideously complex, as is Ada (even the more recent revision, Ada95 I think).
Once again, no panacea of code correctness tools, but with the body of work that has been placed in C; it would be foolish to just "walk away". I've worked with a number of languages; both object oriented and procedural. Many arcane assembly languages as well. In my work, I've come to the simple conclusion that *ALL* languages have issues in many areas. Something like the old adage "all dogs have fleas"...
cheers!