Guest post by No April Foolery: The Portable C Compiler version 1.0 was released on April 1st!
As with so many things BSD, this project proves that good code is timeless and can benefit from literally generations of review. It can build the majority of the BSD base systems (C++ code aside) and is undergoing continuous improvement.
I noticed it was in the queue on April 1st, guess they thought it was a joke.
I wasn’t sure at first either … but after checking it out it turns out it was.
Looks like a nice compiler.
impressive
J/K
This comment reminds me of how different the Chrome browser feels going from Beta to version 10.
J/K
The version numbers simply weren’t bumped, that doesn’t say it isn’t a good compiler.. it was hacked on for many years by many people, not made to impress the masses.
C++ just needs a pre-processor program? Right?
Would they use one already written, or are they developing that too?
that’s something that always intrigued me..
there are many C++ compilers, but all just compile down to intermediate code, not C. Given the difficulty of making a C++ compiler, i’m surprised that there isn’t a “generic” C++ -> C frontend that can be used with the plenty of C compilers available.
C++ was originally implemented via translation to C using a compiler called Cfront. See Wikipedia for more information: https://secure.wikimedia.org/wikipedia/en/wiki/Cfront . That article references a proprietary compiler project that I had not heard of before called Comeau C/C++ which apparently does still use the strategy of compiling C++ by going through C.
I think the problem is that it is useful for the compiler to know about C++’s features later on in the compiler pipeline. Converting them all to C probably makes the compiler harder to write and loses optimization opportunities.
“Just a preprocessor” doesn’t really mean anything.
A preprocessor is, to quote wikipedia, “a program that processes its input data to produce output that is used as input to another program”. You still have to do all the hard work of parsing the code and generating the appropriate IR. At this point you’ll have written a compiler frontent, so you might as well stick LLVM at the backend and emit machine code (instead of generating C and then compiling that with PCC). C++ especially is notoriously difficult to parse, so it doesn’t really make sense to write a C++ to C compiler.
PCC is somewhat tied to OpenBSD. OpenBSD is actually working on eliminating all C++ from their basic tree. For example, they just got rid of groff for that very reason and replaced it with their own man-page preprocessor.
Not exactly.
AFAIK Anders Magnusson (main developer of PCC) started revisiting old code of PCC after experience with porting NetBSD to PDP-10 (KLH10 emulator to be specific). Most problems with porting were related to GCC, not NetBSD itself.
Most work on mdocml (which replaced groff in OpenBSD) were done by Kristaps Dzonsons – NetBSD developer. NetBSD had even Google of Summer Code program related to mdocml.
Nerveless people from OpenBSD had great impact on both projects. Many BSD projects those days are maintained by more than one community.
The version number is version 1.0 of the modern revival. The original versions were more tied to the version of Unix that they shipped with than anything else.
Anyway, I don’t really see the point of this. Yes it’s small and portable and runs quickly, but it can’t really compare to the output quality of GCC or Clang/LLVM. The idea of a compiler that runs superfast but makes slower binaries seems a bit odd.
I think the point is the license. Its not GPL.
Clang/LLVM is not released under the GPL. I think it is released under the University of Illinois/NCSA Open Source License.
see http://llvm.org/docs/DeveloperPolicy.html#license for more information on Clang/LLVM licensing. Oh the other hand what’s wrong with the GCC using the GPL unless you want to make a commercial compiler?
GPLv3 is the issue. None of the BSDs can use GPLv3 sources in their own source tree.
Thus, for example, FreeBSD is stuck at GCC 4.2.1 and the accompanying versions of the binutils stack. Which is why there’s a big push on to get CLang up-to-snuff, and get the source tree compilable and self-hosting on CLang. (Note: this is only applies to the compiler toolchain shipped as part of FreeBSD; users are free to install any version of GCC from the ports tree and use that for their own software projects.)
Why can’t *BSD use GPL V3 licensed programs?
It’s not compatible, philosophically and legally.. someone building a commercial product using BSD would be hindered by the additional restrictions added to version 3 of the license.
There are many comparisons and discussions explaining the problems, google it.
Edited 2011-04-13 21:27 UTC
Ok, I’ve never really heard a convincing argument on this topic. There is the letter from the free BSD foundation a while ago
http://www.freebsdfoundation.org/press/2007Aug-newsletter.shtml
Which reads like absolute FUD to me. I’ve never heard of any case of a product being denied FCC licensing because the end user could change the software. Nor any product suffer “increased support costs” due to people modifying the webserver on a device.
I once preferred FreeBSD to Linux, but I see know with GPV3 that they are more interested in providing freedom to Companies, than individuals. There is no reason why my FreeBSD Desktop should suffer (worse performance from PCC compiled binaries) because some nitwit wants to throw it in a box and sell it as a media server.
Well I guess there is debian BSD, that will still use GNU userland, and probably prefer GCC licensed by GPL 3.
Kettle, meet pot. :roll-eyes:
And where do you see any of the above happening? Where do you see PCC even being considered for inclusion into the FreeBSD source tree?
Wow. That’s all I can say, just, wow. :shakes head:
Firstly PCC compiles quickly and produces slower binaries so that the OpenBSD tree can be built faster on very slow machines (SPARC, m68k, VAX) … and thus testing can commence more quickly.
Also more modern variants of GCC do not support the older archs that OpenBSD (and other BSDs may support). So pcc is a solution to this problem.
The choice to develop pcc was a pragmatic consideration not an idealistic one.
Also I do not see what the problem is about releasing code that benefits everyone including companies. It is the original developers choice as to what license they wish to release their code under. Just because you don’t like it doesn’t mean it is wrong.
Policy. Just like how GPL can’t use proprietary stuff.
Ever wondered why Linux isn’t compiled with the Intel compiler?
sorry my question was already answered
Edited 2011-04-13 21:47 UTC
Not really, if you understand the motivations.
The whole point is that when building releases for testing on older architectures such as SPARC (not SPARC64), the devs can compile the tree quicker … thus they can bug fix, test improvements etc quicker.
Yes my Core 2 can compile the whole thing in about 20 minutes … but it is for the older slower machines which are supported.