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?
For commercial software, pointing to the GCC source isn't that much of a burden if you need to distribute a compiler.
I'd have though the fact a compiler was faster and or lighter would be much more important than the license it uses. Why is that not the case?
Someone please elaborate. What makes this C compiler better than the one in GCC? (I am not asking about licensing issues)
Someone relicense it under the GPL!
This is great, one more step towards GNUless Linux, and making RMS irrelevant!
"NetBSD's" pkgsrc is really everyone's pkgsrc. Try it on what you're running right now.
It's my primary package manager on Interix, Mac OS X, Linux, and NetBSD.
Not a replacement for GCC anytime soon. I'm not sure why there was a need for a compiler licensed for BSD, but it's always nice to see options being developed for anything.
A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort.
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.
Nope.
a) This new version of PCC is nowhere near production quality.
b) NetBSD != Linux
I guess the question should be whether this compiler produces applications that crash less. In my experience, the crashes in current Linux applications are due to in large part, to GCC, though code quality also has something to do with these crashes.
I think of it as if it shall be able to compile and run on PDP11 (even if it may not happen in reality).
Like I don't have enough things to spend my time on. Maybe I should finish my PDP11 page first.
--- Often in error; never in doubt!
# cat
Damn, my RAM is full of llamas.
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.
Still struggling, still in debug, and only works on i386?
Is his submission claiming that "the replacement for gcc has arrived" a joke?
This sounds like good Senior Thesis at best.
Well, that's fairly pointless that it only compiles x86 code. So, it basically means they're competing to make a compiler which is BSD licensed and compiles the most common processor out there, against the biggest GPL licensed compiler on the most common processor?
I really think some effort needs to be put in to support other processors like ARM, MIPS and PPC - after all, GCC is a hardly a diva for any of these (code generation is terrible) and they are not the fastest platforms either. This is where actual performance improvements and quality code generation would actually count for something.
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
Wow, the end of GCC; I thought I'd never see it. Looks like there's nothing left for us GPL guys to do but stop writing software and get real lives.
I hear, out there I mean, there are girls? Is that true?
It seems profoundly stupid to stress out the BSD license as the "most important" feature of this new software.
GPL may not be as free as BSD-license, but one needs to be a real zealot to switch based primarily on this reason. I hope, FreeBSD will wait for it to work on other platforms and only switch because it is "leaner, lighter, and faster".
In Soviet Washington the swamp drains you.
"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
Can't you just check in at slashdot here and there? If you post a number, I suppose I can try to remember, but geez....
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.
An article about a nearly-ready, buggy compiler under BSD license is nice, but really does NOT address how it really stacks up versus GCC. GCC has many options for tuning, optimization, use of things like SSE, etc. GCC also supports many different architectures. How does PCC compare: Price (both $0), license (GPL versus BSD), time to compile, performance of executable, optimization options, use of advanced processor features, 64-bit support, multiple architecture support, use for embedded applications, use for a kernel (BSD, Linux, other), etc.
I'd say "no." Here's why:
I took it to mean that it compiles code 5-10 times faster, but that compiled code itself is usually slower. Not having many optimizations explains both of those "features".
Ben Hocking
Need a professional organizer?
Someone got pissed during the recent license flap when taunted with "yeah, if BSD is so great, why do you all use gcc?" or something like that. So they're trying to send the message to the GPL types that "we don't need you any more."
At least, that's my take on it.
Honestly, BSD vs. GPL has always struck me as one of the stupidest flame wars. It's like that phony debate between "great taste" and "more filling" only people take it seriously.
Personally, I'll license my own software under whichever I feel more appropriate for the task (and that could be either) and tell anyone who complains about it that they can go screw themselves with a rusty chainsaw.
If all we get out of BSD is this kind of news and how Steve Jobs is going to save them, then BSD is dead.
http://gsoc.cat-v.org/projects/kencc/
How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.
Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.
Man page
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
From the summary it's clear this only applies to BSD, but the title implies that it's about Linux (since Linux is the primary reason GCC exists). Thus, I think this should be filed under "bsd" or "flamebait" and taken off the front page. (The reason I think the article is flamebait is because it uses an inflammatory headline to incite Linux users.)
(By the way, didn't slashdot's used to have a bsd section?)
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
Really why not if they want to.
Maybe they thing they have a better idea.
Maybe the don't want to work under the FSF and the GPL.
It could be that they really don't like the direction that GPL is going. Sure right now programs compiled under the GCC don't have to be released under the GPL but when GPL V4 comes out that might change.
Or maybe they just don't want RMS to start ranting about how they should call BSD GNUBSD since the kernel and the user space programs are only part of an OS. It takes a compiler and things like KDE and GNOME to make a usable OS and given that without those GPL programs there couldn't be BSD the BSD should give GNU it's fair share of the credit.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
Just how lean, light and fast does a C compiler have to be?
Surely, even the largest C projects compile in tolerable times on entry-level hardware these days.
I, for one, miss those long lunch-hours when I could call out "Another Martini, Barman! - I can do nothing until the operators page me!".
GCC has been continuously changed not continuously improved. With each new chip that it optimizes for it seems to drop support for an older one. Plus it is dog slow.
Johnson family of products. We will WAX GCC...
(Sorry, Johnson & Johnson popped into my mind as soon as I read that...hehehe). Too much Saturday AM TV in the 70's and 80's for me, I guess....
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Tanenbaum's Amsterdam Compiler Kit works really well, supports about 17 architectures, and includes frontends for C and Modula-2 (among others).
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."
Yeah, good luck with that... Hey, did anyone see the game last night?
"I think the point was that it's hard to justify having two open source compilers for the same language. It's a lot of duplicated work with far less benefit given that the existing compiler has been doing a pretty good job and the "new" kid on the block isn't even ready for use."
Are you paying these people, that you might tell them what they can and can't develop?
I was seriously thinking last night... "what the world needs is another compiler".
It would have been nice to know what the non-licensing aspects of the pcc were, there are already a number of BSD licensed compilers. It is interesting in one of the posts about pcc someone goes on about how the evaluation of x = y changed in 3.x to 4.x of gcc and they were told "suck eggs" by the gcc team. What i dont get about that whole comment is how they think that's going to change with pcc. The original problem still exists - the c standard is unclear (but thats off the point a bit).
It would be nice to see the effort perhaps pumped into something a little more worthwhile. But, rebuilding the wheel is anyone's prerogative, and as long as it makes you happy and perhaps solves a problem for someone, more power to ya! Compilers seemed to have become a bit of a topic of late which is interesting considering how over the last couple of years people have been working hard to abstract away from the actual compiler.
Please. I think RMS would prefer, GNU/NetBSD != GNU/Linux. Obey the beard!
Overall its a good idea. BSDs should not depend upon GPL.
I was a Linux fan and misguided/misunderstood freedom appreciator. After reading recent posts on GPL guys stripping down BSD license, I understood what is meant by freedom. What I followed so far was not freedom, its restrictions. Is conditional freedom a true freedom? Now I very much appreciate all BSDs, especially planning to switch to FreeBSD once it released Ver. 7.0.
There is always the Intel compiler ...
TenDRA is another compiler the BSD people have been looking at for quite some time as well.
“Common sense is not so common.” — Voltaire
I used to use the old PCC on all sorts of weird mini-computers in the '80s. I wonder if it still spits out a "too many shapes" error when functions get too big?
...
At the time people were wondering if GCC would ever be good enough to replace it
Does it run Linux?
You might wanna RTFA before giving us your great insights... One of the main points the OpenBSD folks are interested in it is because they can easily port it over to architectures that GCC has dropped, that the OpenBSD folks still use.
You make it sound as if GCC was the best thing since sliced bread. Okay, depending on what you value it might indeed be, but: It isn't bugfree either, it doesn't really support standards all the way, it compiles fucking slowly and it often completely botches optimization on code that is supposed to be straightforward to translate into very efficient machine language.
PCC (or any other simple compiler) has the opportunity to beat GCC in all of the above.
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.
It took three weeks for one person to write the x86 back end. That is one of the reasons OpenBSD is interested in it; it should be easy to add support for the platforms GCC has dropped.
I am TheRaven on Soylent News
Pasadena City College has always been better than Glendale City College ... it is better funded and is bigger.
s/[i][/i]/
My bicyles
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.
I don't think anyone's actually using GNU/NetBSD.
I am TheRaven on Soylent News
I haven't read TFA yet (plan to ASAP), but I wanted to mention that PCC isn't the only show in town.
TenDRA is a mature, BSD licenced compiler originally developed by the Defence Evaluation and Research Agency (DERA) in the UK. Not sure about pkgsrc, but TenDRA is in FreeBSD's ports.
As for converting an entire operating system over to a non-gcc compiler... well, it's complicated. TenDRA is useful for sanity checking but currently cannot build the FreeBSD kernel, nor even the world. Intel's proprietary icc compiler, on the other hand, can build world just fine (kernel, not so much). Forget about using icc though, if you're a commercial customer ($$$) or if you have a gnu up your butt about free software.
I'd be interested to see how PCC compares vs. TenDRA.
Neither is GCC.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
the floor wax guy?
...the future crusty old bastards are already drinking the Kool-Aid.
Well, playing devil's advocate, because it could insert malicious backdoor code into your program. Obviously, this is not a concern with a BSD license, but I'm just looking at worst-case scenario. A good reverse compiler would probably make that obvious, but ideally at least that would be open-source.
Ben Hocking
Need a professional organizer?
Which part of "It is not yet bug-free, but it can compile the i386 userspace" did you not understand? Its just the kernel and shared libs that don't work yet, which will be fixed shortly.
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.
ELF has a wide set of problems as well, especially on 64-bit.
ACK 6.0 has ELF support on some architectures. It's pretty trivial to add support for other binary formats if you wish, maybe some COFF and PE support?
Now what ACK does not have is something like GNU binutils. But few compiler kits have anything like that.
“Common sense is not so common.” — Voltaire
Yes, but the x86 family still is register starved, and that matters for how you optimise.
Maybe LLMV (http://llvm.org) will be of interest to OpenBSD folks.
Highly BSD compatible. Advanced.
True-Freedom BSD-Style License (no Communistic-License like GPL).
http://llvm.org/releases/1.3/LICENSE.TXT
While LLVM is currently being developed using GCC it's intended to stand alone at some point.
From the LLVM web site: http://llvm.org./
Low Level Virtual Machine (LLVM) is:
1.
A compilation strategy designed to enable effective program optimization across the entire lifetime of a program. LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time and offline (i.e., after software is installed), while remaining transparent to developers and maintaining compatibility with existing build scripts.
2.
A virtual instruction set - LLVM is a low-level object code representation that uses simple RISC-like instructions, but provides rich, language-independent, type information and dataflow (SSA) information about operands. This combination enables sophisticated transformations on object code, while remaining light-weight enough to be attached to the executable. This combination is key to allowing link-time, run-time, and offline transformations.
3.
A compiler infrastructure - LLVM is also a collection of source code that implements the language and compilation strategy. The primary components of the LLVM infrastructure are a GCC-based C & C++ front-end, a link-time optimization framework with a growing set of global and interprocedural analyses and transformations, static back-ends for the X86, X86-64, PowerPC 32/64, ARM, Thumb, IA-64, Alpha and SPARC architectures, a back-end which emits portable C code, and a Just-In-Time compiler for X86, X86-64, PowerPC 32/64 processors.
4.
LLVM does not imply things that you would expect from a high-level virtual machine. It does not require garbage collection or run-time code generation (In fact, LLVM makes a great static compiler!). Note that optional LLVM components can be used to build high-level virtual machines and other systems that need these services.
LLVM is a robust system, particularly well suited for developing new mid-level language-independent analyses and optimizations of all sorts, including those that require extensive interprocedural analysis. LLVM is also a great target for front-end development for conventional or research programming languages, including those which require compile-time, link-time, or run-time optimization for effective implementation, proper tail calls or garbage collection. We have an incomplete list of projects which have used LLVM for various purposes, showing that you can get up-and-running quickly with LLVM, giving time to do interesting things, even if you only have a semester in a University course. We also have a list of ideas for projects in LLVM.
LLVM was started by the Lifelong Code Optimization Project, led by Vikram Adve at the University of Illinois, Urbana-Champaign. Since the first public release, LLVM has grown to include contributions from several other people! We welcome external contributions, so please send e-mail to llvmdev@cs.uiuc.edu if you are interested in contributing code to the LLVM infrastructure.
That seems dumb. They should talk to the LLVM guys about getting it licensed under BSD or the like. IIRC, they state on their webpage that they're open to discussing other licenses, and LLVM totally kicks ass. Someone does need to write a native C and C++ frontend for it though. It currently relies on GCC's frontends.
There's tcc, lcc and bcc. tcc also compiles the Linux kernel, or so I heard, but the resulting binaries aren't as fast as gcc's. Does it do c++, like the GNU compiler suite, and java and fortran too ?
Religion is what happens when nature strikes and groupthink goes wrong.
It might be of no interest to you, but im running "linux environment" on a machine that likely has less RAM than your core 2 duo cache. I dont compile applications for it with GCC, because its code output for ARM is just bloat, and its accompanying GLIBC is bloat squared.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
Good luck. The C99 Standard weighs in at 554 pages - about on par with the Fortran 2003 Standard (580 pages). Writing a small compiler for a large language spec will be no mean feat.
Insightful, not funny! Well, a bit of both. But this truly is a lesson the entire software industry needs to learn. Where are my mod points when I need them...
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Sure, the license is nice, but PCC compiles NetBSD's userland five to ten times faster than GCC. If it was only a few percent worse on code generation, it would save vast amounts of time for developers trying to work on large code bases.
GCC is a pig. The point of resurrecting PCC is that it is not a pig.
When I think of "hot air", I'm more likely to think of posts that make no substantive argument and engage in name calling ("retarded") rather than the work of someone who has written a lot of software, started a social movement for securing software freedoms, and asks for a fair share of credit when people mention the name of a project where the initial author is quite derisive about said freedoms.
I can't agree with your overmoderated post. I think you would benefit from reading the GNU/Linux naming FAQ which addresses your concern about why people ask others to refer to the union of the GNU OS and the Linux kernel as "GNU/Linux" or "GNU+Linux".
Digital Citizen
Yeah, sure I will believe that when I see it.
gcc isn't just a compiler it is an entire philosophy based on supporting computing language grammar.
If you just want a C compiler then perhaps it isn't what you need.
But if you want:
1) Cross platform support of a variety of computer grammars.
2) Very simple, highly modular architecture to facilitate building extensions and finding bugs.
3) The most sophisticated support tools for debugging and optimization of code.
4) A much better license that fosters community contribution and growth without cost.
5) Multi-threaded huge compilation capabilities with tools to do clustered compilations of massive code trees.
6) CPU independant code generation and optimization capabilities.
7) GCC is tried and true and has compiled more code than any compiler EVER has. Beat those stats.
[....list too long due to the limited storage capacity of Slashdot servers.]
With respect to 4, unlike a BSD based license which encourages corporate theft of everyones hard work might I add.
What they are saying is simply impossible.
pcc cannot take over gcc's job because if it did it would be just as large and have the exact same problems as gcc.
One of gcc's job's is to turn C code into binary form, which sure, then maybe.
But gcc does way way WAY too many things to simply be replaced outright by this little C "and thats it" compiler.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
The user-visible portions of userland (X11 and the window manager) are not GNU projects. If a program does not have the magic words `Copyright xxxx Free Software Foundation' at the top of every source file, it is not a GNU project.
The vital portions of userland that are GNU projects are gcc and glibc. Not all Linux systems use glibc, particularly in the embedded world. With a viable non-GNU C & C++ compiler and a full-featured libc, a GNU-less/Linux is most possible.
I, for one, do not believe that glibc (or gcc+glibc) being GNU projects justifies renaming the architecture. For a long time, HJ Lu maintained a forked libc for Linux.
Then the answer is no. I may be alone in the world but I'm perfectly happy with the gcc compiler and have been for years. It does what its supposed to, It is FREE, It is crossplatform (MingW), and it annoys the BSD guys.
Clear Winner. GCC
It has been pointed out here, that people who choose a compiler based on its license are idiots. Well if I'm working on windows I use MingW specifically because of its license. If I'm working in Linux and I usually am, I choose GPL above all others. Count me as an Idiot if you like, But you can shove the alternatives. I know what I am getting and have a reasonable expectation what is coming in the future, and if I need to modify it (Heaven Forbid) I can. BSD is a fine license for people who NEED it. I don't. When given the choice I choose GPL. GCC Slower, maybe so. Code works and I get paid. If it takes 3 hrs for QT to compile. I bill for 3Hrs.
Sorry but, I'm a pragmatist in all things except freedom. I've been burned enough. (Admittedly, I've personally never been burned by BSD code, unless you count Windows.)
OSGGFG - Open Source Gamers Guide to Free Games
Wake me up when you're able to use PCC instead of GCC to do a 'make world'
I'm surprised nobody's mentioned tcc on this thread - it's lighter, faster, and close to a drop-in replacement for x86. The original poster doesn't seem aware of the wider context or they might have mentioned icc too. Even lcc is almost a drop-in, if far less optimising than gcc, and it supports more than just x86 targets.
you had me at #!
You're right. This is the same thinking that brought us OpenRCS...
What does this mean? It means that if the program spits out a bunch of copyrighted text, then there is a copyright on the output. If not, then not. By the nature of what compilers do, it is natural for them to spit out copyrighted chunks text in their output. If gcc did so, then the output would be a derivative work of gcc, and therefore would have to be GPLed.
In fact this is not hypothetical. The gcc folks rejected a number of patches because they would have caused exactly this problem.
And what does GNOME run on? The GNU Windowing system?
Ok, we can ignore tar/grep for most desktop users. We can ignore gcc/make/etc, as they are development tools -- not relevant to anyone but developers. (After all, I'll bet Doom 3 for Linux was built with GCC, but we hardly call it "GNU/Doom3", now, do we?)
No one calling it "Linux" wants to discredit the GNU people, but frankly, I'm glad we don't have to acknowledge every little contributor in the name. I run an operating system which I call "Kubuntu", and occasionally "Linux" so people have something to refer to. I use KDE, some GNU utilities, some Perl and various other things not even GPL'd, and some things I'm not sure are entirely legal, like libdvdcss.
GNU is pervasive in my system -- but no more pervasive than any other random element, like X.org.
Don't thank God, thank a doctor!
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.
"I think the point was that it's hard to justify having two open source compilers for the same language. It's a lot of duplicated work with far less benefit given that the existing compiler has been doing a pretty good job and the "new" kid on the block isn't even ready for use."
Man, I feel a sudden "Bitkeeper vs Git" rant coming on. Oh, wait. Just gas.
They say it builds the tree much faster - I can believe that - but does the code run faster?
Could you back up #3 with some quotes?
In any case, let me introduce position #4: The system I run today has all kinds of elements in it, from all kinds of projects, open and closed. GNU is one of them, along with KDE, QT, X.org, Perl, Apache, PostgreSQL, the Ubuntu/Kubuntu projects... Hell, the next version of KHTML (Konqueror's rendering engine) will be incorportaing code from Apple, for fuck's sake!
To be completely fair to all parties, I'd have to call it: GNU/TrollTech/KDE/X.org/Perl/Apache/Postgres/Ubuntu/Kubuntu/iLinux.
Oh wait! I forgot the hardware manufacturers! What was I thinking? I guess I better add an AMD/nVidia/BioStar/KOSS/SysKonnect/Realtek/Creative/Sceptre/Logitech to the mix.
Starting to get the idea?
Frankly, I'd rather call it whatever I want and deal with RMS complaining, than have to read the entire list of contributors every time someone asks me what OS I run. So I call it Linux, KDE, Ubuntu, and Kubuntu. The GNU project has plenty of visibility -- I see it every time I look up the docs for a tool I'm using (GNU Make, Gnu C Compiler, etc), not to mention the occasional time I fire up the Gimp.
Don't thank God, thank a doctor!
See the last sentence of that page : http://www.ludd.ltu.se/~ragge/pcc/
According to Wikipedia, a modified version of lcc was used for compiling Quake III. It seems to me, this compiler would be far more maintainable, but for some reason, the world doesn't seem ready for literate programming.
"There's no reason to duplicate effort:"
Developers are people, they cant be moved around like currency.
Scratch an itch: People program from inspiration and/or motivation, if this is how these developers are willing to donate their time to the community
who are we to say they should try and do something else.
The free software community is not a monoculture, competition amoungst projects can lead to higher quality software for all those competing.
Anyone who wants to deny this please tell me, why are BSD guys so proud of themselves when MS forks them but get off their panties like crazye Hezbolla fanatics when their code is used in GPLed projects?
OK, the onchip cache on my core 2 duo is many times larger than the full RAM on any PDP-11 I've ever heard of. So why should I be interested in a buggy compiler that wants to fit into tiny PDP-11 constraints?
Have you ever looked at the source to GCC? I tried to add a very simple variant of a supported architecture, and eventually gave up. It's nasty in there. I think the point is to make it so it fits in one's head, not just in a PDP-11. After all, if it's so complex nobody can work on it, what use is being free?
GCC is buggy, too, of course. The difference is that I have no chance of being able to fix the bugs in GCC.
That is the beauty of choice. If it is not interesting to you then obviously it was not intended for you. Keep using GCC.
BTW, For all those worried about their precious Linux this doesn't have anything to do with Linux in the first place.
There's no logic to supprot "Linux" as a name, and there's actually relatively little logic to support a desktop environment or a distro as a name.
At least if we're talking about who should be credited in the name, the logical answer really comes down to this: Everyone has an equal claim. However, you don't see X.org throwing fits and refusing talks or interviews with people who refuse to call it X.org/Linux, even though X.org is arguably as much code and as much a necessity of a modern Linux desktop as the GNU tools are.
(Yes, X.org probably requires gcc and glibc. However, no one would care enough to continue developing either if they had to do so without a GUI.)
Actually, there is one very, very good reason for using "Linux" as a name: It tells you what's compatible. A clueless person who buys, say, UT2004 or Quake 4, knows that it's compiled to run on a Linux kernel. Most of the other things aren't as relevant -- X.org just happens to be the best X server, but it could theoretically run under something else. Ubuntu is slightly more relevant, but these games are proof that you can distribute a distro-neutral binary.
As far as many applications are concerned, Linux is the operating system, the rest are just applications. Yes, some of them are required, but this is also the case on Windows -- sometimes you need a particular video codec installed, for example, to play pre-rendered cinematics in a game. The codec might be part of Windows Media Player, but isn't part of Windows. There are also things like Steam -- you need Steam installed to play Half-Life 2, but we don't consider Steam to be part of the operating system.
So, when you get right down to it, I would call Linux the OS, and a particular distro would be like a version or "flavor" of other OSes (like XP vs Vista, or Ultimate vs Home Basic). Not out of any logic for who should get credit, but because it tells customers what they need to know about application support and customer support, which are really the only two places the customer would care about the specific OS they're running.
Don't thank God, thank a doctor!
1. Is is C++0x ready?
2. Does it work with FreeGLUT or MESA for OpenGL support?
3. Can it make ice cream?
The Rapture is NOT an exit strategy.
in terms of providing ways of verifying, at least *type* correctness.
In terms of verifying the correctness of the implementation of an algorithm... you have to accept that is a practice that will never exist outside of academia.
That's not to say we should never prove things about algorithms, but rigorous proofs should not be done on production code and on production languages. Use psuedocode if you want a proof. Correctness of algorithms in production code comes from the fact that those algorithms are 1. derived from well known and proven algorithms, 2. are "obviously" correct, 3. have unit tests to provide *empirical evidence* for the correctness of their implementation.
Real companies put more emphasis on empirical evidence of program correctness, especially unit tests, than analytical solutions. Type correctness is a powerful tool, but aside from that it's pretty much impossible to determine program correctness while still allowing for efficient low level programming constructs that are necessary in production code.
If you go back to the old gnu newsletters there is the bald announcement along the lines that gnu needs more attention and it is a good thing that it can get it if everyone is aware that there is gnu in their linux distribution. Personally I didn't agree with it when the silly LiGnuX name was suggested and then when it was revived as the gnu prefix. The water got muddied a bit more when there was the insistance by people that should know better that linux was the kernel of the gnu operating system and this line was swallowed whole by newbies that really should look up a textbook. The whole thing is annoying to those of us that remember the response RMS used to give to any question asked about linux some time ago "Linux? Never heard of it - haha". Going from that bad joke to implied ownership in under a year is what I consider bad form even if you think it is for a good cause.
Just because you compile with GCC doesn't make your system a GNU system. Otherwise, the Game Boy Advance system would be the GNU/GBA, as Nintendo provided a port of GCC as part of the GBA SDK. (Homebrew developers use a different port of GCC.)
If I had to make a guess as to what deserves a GNU/ prefix, it would have something to do with the userland, which executes even when nothing is being compiled. As far as I can tell, only Linux uses glibc and GNU Coreutils out of the box. FreeBSD has BSD libc and BSD Coreutils.
Ken Thompson
Link
You are being MICROattacked, from various angles, in a SOFT manner.
Wake me up when it supports C++0x.
Until then PCC will be a toy...
Cheers
Ben
Complex specs -/-> complex implementation. The spec describes what ALL implementations must do and need not to do with all sorts of odd corner cases that just aren't your problem unless you are trying to do things in an unusual way.
The Electric Railway Association Presidents Conference Commission was set up in 1933 to develop a streetcar that would better meet the competition from cars and buses. The resulting design was produced in the US from 1936 to 1952.For the non-streetcar fans, PCC = Portable C Compiler.
A Shadeless room is a brighter room.
Here is the license in full. What part of this says you can't change the license?
* Copyright (c) <year>, <copyright holder>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* * Neither the name of the <organization> nor the
* names of its contributors may be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY <copyright holder> ``AS IS'' AND ANY
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY
* DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Furthermore, please see the Wikipedia article on BSD licenses, which reads, "It is possible for something to be distributed with the BSD License and some other license to apply as well. This was in fact the case with very early versions of BSD itself, which included proprietary material from AT&T."
When did Linux come into play? The summary only stated [Open,Net]BSD.
But, since you asked, diversity == good.
It seems many do not see the benefit of a BSD licensed compiler. Here and on Slashdot, many think its a waste of time to develop another compiler. Some see its a good thing because it is faster. Faster is not the point. It can even be slow and inefficient for the start. PCC's advantage over GCC is license. Why?
Day by day computer CPU chips getting faster, most importantly becoming multi-core. Recently Tilera (www.tilera.com) released a processor with 64-cores. And they are working on a 128-core processor. Intel also working on a similar multi-core processors. These multi-core processors are important for video encoding, simulation, gaming, etc. Techniques of efficient code generation for such chips may be only known to the manufacturer. May not be even possible release specs of internal architecture in such a competitive world.
Its because PCC is BSD licensed, Tilera, Intel, AMD and other processor manufacturers can develop code generation modules in closed-source and release to PCC. What OEMs require is to sell their chips without exposing internal working. Its really up to them to release in either closed-source or open-source. So that BSD users can benefit by the tremendous computing power these processors provide. The PCC can even provide a compelling reason for people to switch from Linux to BSDs. Can these OEMs release such a closed-source module/driver for GCC? No, why? GCC is GPL-based which requires them to offer the source code. That is why, OEMs release such modules/drivers to Microsoft Windows. Therefore, a BSD licensed compiler is a very good news. What the PCC developers should do is, design it in such a way that anybody can extend its functionality by way of external plug-in modules. What people out there who are competent should do is help PCC.
Sagara
Undefined behaviour? What's wrong with that? Do you really want to standardise, say, what happens when you reference a dangling pointer? That would require every pointer access to be wrapped in checking code, with metadata stored with every pointer, introducing a massive overhead on the lowest level operations. C is low-level. If you don't want a low-level language, then don't use C.
Every usable OS, maybe, although I could probably find some niche OS written in Java or something.
Oh, and they aren't all written in C. I'm not sure if Windows is entirely C, or some combination of C/C++, and the same may be true of OS X, sort of (it'd be objective C). But honestly, any modern OS is also going to need significant chunks written in assembly. If you're going to have to do some low-level stuff and some high-level stuff, why not use C/asm only where needed, and use another language for the rest of the system?
But never mind. I shouldn't argue too hard, mostly because while I'm convinced a good, entirely non-C OS can be written, even without memory segmentation (see Microsoft's Singularity), I haven't done it, and to my knowledge, no one has.
Don't thank God, thank a doctor!
That was what I said wasn't it?
;)
Compiling x86 code now brings them zero steps closer to the goal
There is MIPS, VAX, PDP10 code generators in the source code but, OpenBSD never worked on any of the weirder ones and the MIPS support is busted. I reckon they should not focus so much on the "architectures that gcc has dropped" but on the architectures gcc sucks at (everything except x86).
*smirk*
:D
That would be nice, though, right? A mobile phone compiler that can actually run at a decent speed without using up a whole flash card?
Nintendo DS Homebrew could really benefit from pcc on ARM.
So? Just because a non-GNU Linux can exist doesn't mean that no system should be called GNU/Linux. The name applies only to systems that use a Linux kernel and GNU userland, the same way that the name "BSD" only applies to BSD systems and the name "Windows" only applies to Windows systems.
LLVM is the one to watch. Currently, llvm-gcc uses GCC's front end but Apple, a major funder of LLVM, have recently released the source to clang, their C compiler. No GCC in sight. http://llvm.org/ http://heisenbug.blogspot.com/2007/07/compiler-with-good-clang.html
That's like asking if Linux runs Photoshop or World of Warcraft.
;)
It's in poor taste at the very least.
(not to mention that C++ is such an appallingly horrid language that no compiler with any sense of propriety would dream or admitting it knows about such things. One might as well ask if it's got a front end for Visual Basic. The very idea!)
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
I never claimed it could be; I just said that the linux kernel is not a good or fair test of a C compiler. Are you disputing that?
I am trolling
You are right on about this. The 80286 had the beginnings of what was required to write solid operating systems. The boundary protection and memory virtualization started giving the microprocessors the virtual memory semantics that we were used to from the mainframes. Aside from features that were missing (later added in 80386) and the loadall saveall debacle (security through obscurity failure), things were looking bright for the operating system writers targeting micros. Unfortunately, Microsoft made a decision not to use the boundary protection in their new operating system called "Windows". They ignored most of the work that Intel did providing support in the silicon for a decent micro operating system. The boundary protection could have been built into the programming language and runtime. Things would have been much better in the long term. I guess in the early days, they (MS) didn't want to use the memory space or cycles to secure the environment, although later they were willing to virtualize the entire runtime in that name (.NET).
Unfortunately, Microsoft made a decision not to use the boundary protection in their new operating system called "Windows". They ignored most of the work that Intel did providing support in the silicon for a decent micro operating system. The boundary protection could have been built into the programming language and runtime. Things would have been much better in the long term.
16 bit Windows did use it, but just not for protection.
Originally 8086s had a simple segmentation mode without protection. Each address was built up of seg<<16|offset. Since both segment and offset were 16 bit, this limited the address space to 1MB. Famously, the designers of the IBM PC reservered the upper 384K for IO, and this is where the 640K limit came from.
Later on the 80286, protected mode was supported, where the value you loaded into a segment register was a selector, and index into a table of segments. The CPU supported different privilege levels called Rings with only the highly privileged ones allowed to create entries in this table.
16 bit Windows did used 286 protected mode - it had to to get access to memory above 1MB. When it loaded it would install a DOS extender which would switch the PC into protected mode and allow 16 bit protected mode tasks to run on top of DOS. Since the 286 didn't allow you to switch back, each call into DOS used a triple fault to reset the processor and some Bios code to jump back into Windows.
It was even possible to allocate buffers bigger than 64K. In that case, windows would set up an array of selectors for each 64K chunk. If C code wanted to access an arbitrary location in the buffer, the compiler would work out which 64K chunk it was in, load a segment register with the corrrect selector (this was a very slow operation since microcode in the 286 had to check permissions), calculate the offset and load it into one of the normal registers and then do the segment read. This was an incredibly slow process.
It's also worth pointing out that 16 bit Windows used protected mode to get access to more memory, the like Dos the OS didn't protect itself from being damaged by third party applications. And it didn't stop third party applications damaging each other. As Walter Oney put it the philosphy was that it's a personal computer after all - If you're a programmer you can do what you like to it, just like you're free to run your car without oil until it seizes up.
Once the 386 came out and allowed offsets into segments to be bigger than 64K Windows would even set the limit on the first selector to allow you to access the whole buffer with operand size overides. The 386 also supported Virtual 8086 mode, so protected mode could jump into DOS and segments would work like a 8086. But loading segment registers was still a very slow operation, and Windows NT and Linux which are both designed to stop applications corrupting each other or the system both used page tables to do it instead. But page tables don't protect against buffer overruns.
Mind you segmentation only protects against buffer overruns if you malloc the buffers. Automatic variables on the stack are not protected. And allocing a stack variable is just a subtract instruction - it is orders of magnitude faster than calling into the OS, switching to Ring 0, allocating the memory, filling in the segment table and the returning to the caller who would load the selector into a segment register. Worse, there are very few segment registers, an each time you access any buffer you need to reload one. On a 286 there is CS,DS,ES.CS and DS are needed for near code and data, so only ES is free for far pointers. The 386 has FS and GS too, but three registers with very slow loads is not a recipe for a speedy machine.
So Microsoft tried it and it was slow. If they'd have used it enough to avoid buffer overruns - i.e. malloc every buffer rather than allocating some on the stack it would have been really slow. And so all modern OSs rely on the page table for protection instead of segments so they can run on multiple processors. In x64 mode, segment limits aren't even checked by hardware anymore.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
If BSD people are unhappy about the current state of GCC, whatever their objections are, why don't they just fork it again? After all, this was what egcs was all about.
If their fork proves worthy, leaving license problems away, people will start using it (even the Linux kernel). As many people, including God Linus, say, "code talks"! Instead of reinventing the wheel, fork and improve!
Egcs has ultimately become the "real" GCC after all, hasn't it?
How can a single C compiler replace a compiler collection which supports Ada, C, C++, Fortran, Java, Objective-C and Objective-C++?
Answer: It can't.
Martin
Yes and no. Obviously, if you want to ship a binary, you obviously want as many optimizations as possible without changing the semantics of the program. However, some optimizations take a lot of compile time, so when you are changing the program and running tests, it can be quite a nuisance having to wait a long time for the compiler to finish only for your test to tell you that you still missed a bug or introduced a new one and you have to wait for the compiler again after the fix. It can be somewhat mitigated by compiling incrementally but a fast compiler would still be useful in such a situation./p?
So then write it in Ada.
The *BSD forked something quite a bit lighter than GCC, namely GAS, in 1993; they implemented a useful feature (dynamic shared libraries, à la SunOS) with it; since the main GAS thread went to ELF and BFD, they had to support themselves their fork; it proved to be too heavy a weight for them, so they were "forced" a few years later to drop the enhancement, or at least making it deprecated/obsolete. So I do not believe forking GCC as being rational, at least for a mainstream projet like *BSD.
learn to write lisp to understand abstraction.
Learn to write correct C to understand application.
Z. Well, yeah, it implements a bunch of nice mathematical tools that are good for checking algorithms.
But do you understand the run-time?
In my opinion, C has suffered as much as it has benefited from the standardization process. (Obligatory thanks to Microsoft as one of the largest influences there.) It's a lot harder for me to understand the run-time of a C program now than it used to be, and if I can't understand the run-time, what good is it if I know my algorithm is theoretically correct? By the time it gets to the metal, timing issues and other semantics issues of getting the abstract stuff mapped to the bare metal may (for example) have pushed my checks for corner cases way out of whack.
But I look at the alternatives. Java used to be fairly understandable. Now it's fast enough to use on a lot of stuff, but it is no longer understandable. (I know that no one mentioned Java, but I just did, as an example.)
Every interpreted language I've seen makes all sorts of implicit assumptions about the run-time behavior that are counter-intuitive to me. I used to think it was just me, but when I ask fans of said language to explain, their explanations are generally full of stuff that turn out to be their personal interpretations of things they don't understand. So the best they can say is that they think they can demonstrate correctness. Or maybe they can demonstrate that they think it's correct.
Or, at any rate, that's the way it looks to me.
While I can imagine an architecture in which your loop never goes negative (explicit sign bit not involved in shifts) I can't imagine an architecture in which the loop would fail to go to zero. I mean, on any binary ALU, that 1 is just one bit, and when it runs off the top there is nothing but zeros left behind.
Hmm. Okay, I can imagine it now -- the CPU sets a flag when a shift tries to shift a one bit out of a register, and faults with the contents of the register unchanged. And you have some code somewhere that ends up catching the signal so that your loop doesn't end in a fault. Of course, multiply will be more likely to be guarded in such a way than shift.
On the one hand, yeah, people tend to write to the compiler as if it were standard.
On the other hand, BSD userland is a lot of test code written to teh GPL mark. Kernel, and other stuff will increase the balance of relatively correct..
I can tell from my last sentence that I must have been asleep by the time I hit the send button.
/* Do something that requires i to double every pass to the limit of an int. */;
What I meant to say was there is a lot of GCC compatible source code in the openBSD and netBSD distribution and packages that will test most of the points like the multiply-by-two example given. Well, maybe not that particular example, but the point I thought I was trying to make was that the bulk of the code being (relatively) standard would tend to push the development of any alternative compiler away from encouraging dependency on implementation of undefined behavior.
But thinking that over with a clear head, I can see that, _if_ some BSD programers had pet behaviors that they liked to program to, existing more-or-less correct code does not prevent such dependency being supported, and even promoted. GCC, of course, being a case in point.
However, the openBSD programers are pretty much sticklers for standard source code. More than any other group, this group is going to tend to stay away from undefined behavior, because dependence on undefined behavior is a good way to open future security holes (like the sign overflow business).
As far as DSPs, I think there is a good point to be made:
The C standard tends to try to bend over backwards to try to accomodate non-mainstream CPUs, and that is not what a standard should do. Standards should not encode all the exceptions, otherwise the exceptions become the standard.
In the case of DSPs, I can think of very few DSPs that can fully support the standard without a lot of run-time support that would get in the way of processing signals digitally. So it makes little sense to attempt to directly support DSPs in the standard.
It makes more sense for the standard to define methods by which a non-standard compiler can qualify and quantify departures from the standard.
In this case, not only do we want to be able to query the actual width of the various integer types, but we also want to be able to query the operational base, the sign behavior, and the behavior of shifts. And we want the standard to provide a way for CPU venders to declare their support for a subset or dialect of the standard.
Kind of like being able to ask someone, "Are you from Texas?" although you really can't be sure in the human case which subdialect of Texan the person you're talking to is speaking. (We is proud o' ow-uh lo-cowl dye-lectix in Texs.) Then you could know such things as that "all" has to be able to parse as a "oil" as well as "every".
In the specific case of the loop that depends on shifting bits out the top, you might enclose the loop with something like
#if ! defined STICKY_SHIFT && OPERATIONAL_BASE == 2 && ( SIGN_FORM & TWOS_COMPLEMENT )
i = 1; while ( ( i >> 1 ) > 0 )
#else
# error( "Compiler does not support this optimized algorithm." )
#end
(Man my C's getting rusty.)