Slashdot Mirror
GCC Turns 25
eldavojohn writes "With the release of GCC 4.7.0, the venerable and stalwart constant that is the GNU Compiler Collection turns twenty five. More ISO standards and architectures supported with this release and surely more memories to come from the compiler that seems to have always been."
Actually, while PC duffers were futzing with 16 bit Computer Innovations C, Lattice C, Microsoft C 1.0 in 1983, which was pretty much just a ripoff of Lattice C, then through the 80s with Microsoft C 2.0 through 6.0, with the first hesitant entry to 32 bits in 5.0 near the end of that period (even though there was no proper Microsoft 32 bit OS available yet at that time), REAL embedded programmers were working with 32 bit 68000, 68010, and 68020 using Green Hills C and compact deterministic real-time multi-tasking kernels such as VRTX.
Green Hills C was a significant improvement on the Portable C Compiler that came with SunOS and other BSD based unixes in those days.
When gcc finally matured, it was an ENORMOUS boon. The action nowadays is moving to Clang/LLVM though. With Clang, you don't have to compile a separate version for every cross-compile target. Every Clang executable is capable of producing code for any of the supported targets just by using the right run-time options. Of course, this doesn't address the point that you still need appropriate assemblers, linkers,libraries, startup code etc for each target. But they are trying to get a handle even on that with the Clang Universal Driver Project.
No, it doesn't. Distributions are evaluating it right now and it is failing big time. Even Xcode developers are pissed off that Apple dropped gcc. That shit ain't fully baked, and imbeciles like you who recite Apple propaganda without thought need to pull your heads out of your asses.
Pastel was an extended Pascal compiler developed by LLNL for the S-1 supercomputer project
http://www.cs.clemson.edu/~mark/s1.html
It, and several other significant pieces of software, including the SCALD hardware design language
were made freely available by LLNL. I have one version of the compiler, which was donated to the
Computer History Museum by one of its authors. I have been looking for the other pieces since the
late 80's.
If you look at the GNU Manifesto, RMS was also looking at using the MIT Trix kernel in the early days
of the project.
Deliberate misinformation. You are free, of course, to do whatever you want to with binaries produced by GCC. GCC's license is completely irrelevant unless you're modifying or extending GCC itself.
Nice try, though.
GCC's license is completely irrelevant unless you're modifying or extending GCC itself.
In fairness, Clang and LLVM are designed to be used as libraries and integrated with other projects. Imagine that your favorite text editor uses Clang's own parser to generate its syntax highlighting and check for errors as you type. With the GPL, your editor would likely have to be released under the GPL. Now, I like Emacs so that's not a deal-breaker for me. I can see why Apple and other non-GPL editor authors might not like it, though.
Dewey, what part of this looks like authorities should be involved?
Are you an Apple shill in your spare time?
I'm trying to read this thread, and I have to put up with your repetitive posts about how great clang is. Why don't you read some of the replies to your crap? They do a good job of debunking your claims. I have mod points, but I just hate moderating people down, even if they waste my time repeating unfounded assertions (also known as bullshit).
True, but adding // comments would take 10 minutes (assuming you know the code), and giving the ability to declare variables wouldn't take long either.
You forget about all the associated red tape. Even a minor feature has to be tested, and some QA ultimately has to sign off for that. It also has to be documented by tech writers, complete with code samples, and said documentation to be translated to all supported languages (I believe over a dozen now for VS). Any associated user-visible output (e.g. new errors/warnings) also has to be proof-readed and translated. It all adds up.
But let's be honest, is there any reason a company with Microsoft's resources can't keep up with gcc?
It can, if that were the goal. But the ultimate goal is to earn money, same as for any other for-profit company. Hence, things aren't done because they are neat or the Right Thing or because everyone else has them. They're done because the expected profit from the feature - whether direct (from sales of the product) or indirect (from sales of other products propped up by the SDK, like, say Windows) - exceeds expenses. Even more importantly, resources being large but still limited, for every feature the question is not whether it is profitable in and of itself, but whether it is more profitable than something else that could be implemented in its place. It's that stack ranking that really kills C99 support - there's always something more important (read: more profitable).
Of course, people aren't cogs, and sometimes they feel hard enough about something - purely out of the desire to do the Right Thing - that they play bureaucracy games to come up with a plausible "business case" for their favorite cause, and ultimately convince the management that calls shots to let them put it in. But, there's no-one there who feels hard about C99 (or at least harder than a dozen other things that need to be done first, preferably yesterday - like, say, variadic templates...)
What's all this about GCC being slow? It's one of the fastest (in terms of compile time) compilers I work with regularly. You need to try out some highly optimizing compilers for embedded processors sometime to reset your expectations.
Some real numbers: I just recompiled (with all the optimization bucky bits turned out) my Intellivision emulator and SDK. That's just over 100K lines of code. Took 3.75 seconds with make -j6. "But that's a parallel make!" Fine, I'll do it again tying three of my computer's CPUs behind its back: 13.54 seconds. (Only 8.6 CPU seconds.) At work, it can take 5 seconds just for RVCT (ARM's compiler) just to contact the friggin' license server. Or maybe it's our NFS servers. Hard to say.
Ok, now to be fair, that's nearly all C code. C++ is a whole 'nuther animal. But much of that is C++'s fault, or more correctly the modern C++ libraries. The template processor is a Turing complete functional programming language, if you sneak up on it sideways and catch it off guard. The STL and Boost folks have perfected that snipe hunt and made an industry out of it. That means that C++ code can compile a bit more slowly. (Fine: "a bit" is an understatement. More like a quadword.) BTW, my comment on STL and Boost is not meant to be a flame of their work. It's incredibly useful stuff. But, I consider a bunch of what they're doing something of an abuse of C++'s limited mechanisms. If C++'s metaprogramming facilities were more deliberately designed for this level of use, I think compile times would come down and we'd avoid the "thirty pages of spaghetti because you forgot a comma" error message experience.
The book "C++ Template Metaprogramming" has a rather enlightening chapter (Appendix C) on compiler-time performance for various C++ features. (Get a glimpse here. Just search for Appendix C.) Unfortunately, it's not terribly up to date--my copy says (C)2005--so it measures GCC 2.95.3 and GCC 3.3. GCC definitely was not a performance leader in that era, but most of the compilers were pretty bad. I'd love to see an updated version of it for the latest crop of compilers. I seem to recall finding a website a couple years ago with updated data that showed GCC fixed some of the quadratic algorithms in this space, but I could be dreaming it. If anyone actually has pointers to some data on this, that'd be great.
Program Intellivision!