|
|
Log in / Subscribe / Register

A potential competitor for GCC: pcc

By Jake Edge
October 24, 2007

A C compiler with a long history in the BSD world has recently been imported into the package repositories of the major BSD variants. There are thoughts that it may, perhaps, replace GCC for BSD development some day. A competitor to GCC might be very well received in some parts of the Linux community, as well – grumbling about the compiler, its speed, and the code it generates have been heard for some time.

The Portable C Compiler (pcc) came from Bell Labs in the 1970s and shipped with 4.3BSD-Reno. It was eventually replaced by GCC in 4.4BSD, but it is a much simpler compiler than GCC, while still targeting many architectures. More recently, most of the compiler has been rewritten by Anders Magnusson and others. It will currently compile many of the BSD userspace programs, even linking to libraries compiled with GCC. It is also available in RPM format for Fedora Core 6 and Fedora 7.

Interestingly, pcc has Caldera copyrights as part of its license; well before they became the SCO Group and sued their way into pariah-dom, Caldera released "ancient Unices" under a BSD license. pcc is BSD-licensed as well, which has some obvious attraction for the BSD world, but licensing is not the primary motivation. The reasons for working on an alternative compiler are more complex, with OpenBSD leader Theo de Raadt saying that one of the reasons is "fighting against an open source monopoly".

There are several big issues with GCC for the BSDs, but regularly breaking support for architectures that they still use seems to be one of the biggest. The feeling is that GCC concentrates on Linux for x86 and PowerPC to the detriment of other operating systems and CPUs. By having a compiler whose developers are more aligned with the goals of the BSD family, those kinds of problems can be avoided.

The GCC development process can be politicized and difficult for developers – the GNU coding standard can be a real barrier for example. Each new release comes with its set of new features, but with new bugs, especially in the optimizer, that make it difficult to adopt. Supporting multiple GCC versions for a codebase can be an enormous headache. Marc Espie, GCC maintainer for OpenBSD, outlines multiple frustrations with GCC while advocating a new compiler.

The speed of compilation is another area that GCC is criticized for. With each new release, GCC is typically slower, sometimes much slower, in doing its job. Currently pcc is five to ten times faster – a big difference for developers who are constantly recompiling code.

Some of the complaints are reminiscent of those that led to the GCC/ECGS fork, but instead of forking, the BSD folks are investigating an entirely different codebase. Another big barrier to developer involvement in GCC coding is its complexity. GCC is huge and quite daunting to someone who just wants to start hacking on a compiler. It is also difficult to audit for security, one of the hallmarks of the OpenBSD project. pcc is small, easier to understand and audit.

GCC is an important piece of the free software world, it has been for decades and will be for more in the future. It has enabled most of the software we use every day and for that we should be grateful to the GNU project and the GCC developers. It is not without its warts, however; a competitor might just bring about some changes.

pcc is still a long way from supplanting GCC, even in places that would like to see it happen soon. It will be interesting to see – and good for both Linux and the BSDs – if pcc can get to the point of being a viable competitor. Some worry about forks and multiple projects with similar goals (i.e. GNOME and KDE) because they may dilute the efforts of each branch, but that concern has proven to be largely unfounded. Either the technically superior project wins out, or they all coexist more or less happily.

de Raadt is right to be concerned about monopolies, free software or otherwise. Two – or more, see the LLVM project for another option – C compilers can only be good for the free software world. A variety of approaches to both code and project governance allows more participation by more developers. If some day pcc is clearly the superior choice, GCC will change or fade away. That is free software Darwinism at its best.


to post comments

*NOT* A potential competitor for GCC: pcc

Posted Oct 25, 2007 2:12 UTC (Thu) by qu1j0t3 (guest, #25786) [Link] (2 responses)

I cannot believe this April Fool's Day joke still has legs. If anyone wanted an alternative to gcc (few do), there are credible options. pcc is not among them.

*NOT* A potential competitor for GCC: pcc

Posted Oct 25, 2007 2:57 UTC (Thu) by pabs (subscriber, #43278) [Link] 

Of the competitors you mention, only tcc is free enough. That is hardly a gcc competitor (i386
only).

*NOT* A potential competitor for GCC: pcc

Posted Oct 25, 2007 7:32 UTC (Thu) by bboissin (subscriber, #29506) [Link] 

Yes, it's a little bit sad to see lwn falling for this joke. pcc can be nice for educational
purpose but that's all. Please use llvm or open64 if you want an alternative.

Two words

Posted Oct 25, 2007 2:42 UTC (Thu) by ncm (guest, #165) [Link] 

Oh, please.

This is nothing more than the BSDers' "we wish we weren't so dependent on GPL code" refrain.
What's sad is to see LWN fall for it.  Probably the best thing all around would be for LWN to
pull the story and try to forget.

A potential competitor for GCC: pcc

Posted Oct 25, 2007 3:02 UTC (Thu) by dvdeug (subscriber, #10998) [Link] 

Grumbling about the compiler, its speed and the code it generates has been heard for every
compiler since the first one. In particular, this compiler won't produce better code than GCC;
the goals of simpler, more backward compatible and less emphasis on a few important processors
make it hard to generate faster code for most people.

Some of Marc's complaints have point, but maintaining a multi-platform, multi-CPU compiler is
hard. The kernel to kernel comparisons between Linux, NetBSD, OpenBSD and FreeBSD didn't look
great for OpenBSD and NetBSD; it's hard to compete if you don't have enough maintainers. If
the maintainers for this compiler can create a working compiler that compiles real C (not just
"many of the BSD userspace programs", all of them plus user programs) that targets all the
processors they need, will they manage to follow the C standard and produce reasonably fast
code and good warnings? (I'm really curious if PCC will actually produce better warnings, or
if they will just pick a different set of false negatives and false positives and declare it
better.)

Also, at least some of the blame of the problems with platforms becoming unsupported is that
nobody was testing the compiler on these platforms. Perhaps being closer to the BSD community,
the PCC developers will manage to find people to test PCC, but if Marc Espie can find testers
for PCC, he could have found testers for GCC.

Furthermore, I find it unlikely that they even plan to produce a full competitor for GCC; most
likely C++ will still require GCC, and despite the kibitzing, there will be platforms, both
non-BSD OSes and CPUs the *BSDs don't run on, that GCC targets and will continue to target
that PCC won't.

A potential competitor for GCC: pcc

Posted Oct 25, 2007 3:16 UTC (Thu) by clintonroy (subscriber, #6660) [Link] 

They're just scratching an itch, nothing wrong with that. More power to 'em.

Clang

Posted Oct 25, 2007 3:56 UTC (Thu) by akanaber (subscriber, #23265) [Link] (3 responses)

Chris Lattner and other LLVM people are working on a C Compiler called Clang (a C/C++/ObjC frontend to go with the LLVM code generator back-end), which looks way more interesting than pcc, to me anyway. It has lots of nice features (good diagnostics as well as being fast, designed to support integration with code-analysis tools) and by using LLVM it already has a good optimiser and lots of target platforms.

(the older way to use LLVM as your compiler is llvm-gcc which lashes the GCC frontends to LLVM by translating representation languages, and so inheirits some of GCC's performance and code complexity)

It's BSD licensed too. There's a good online talk (Clang stuff about 19 min in).

Clang

Posted Oct 25, 2007 6:28 UTC (Thu) by MisterIO (guest, #36192) [Link] 

Wow, Clang is really interesting!

Clang

Posted Oct 25, 2007 7:18 UTC (Thu) by Frej (guest, #4165) [Link] 

Yeah clang looks very interesting, but i don't think they aim for replacing gcc ... isn't more
about replacing gcc+gcc-output-parser in Xcode?



I might be wrong though...

Clang

Posted Nov 4, 2007 22:53 UTC (Sun) by roc (subscriber, #30627) [Link] 

Most of those claims for CLang are actually promises and goals, since CLang can't actually
generate code yet (at least it couldn't at the time that talk was produced).

An interesting historical artifact

Posted Oct 25, 2007 4:40 UTC (Thu) by JoeBuck (guest, #2330) [Link] (18 responses)

Not mentioned is that it's a K&R C compiler, so it accepts a dialect of code that only old folks like me know how to speak, and it won't compile modern code. Still, it's nice to see a pointer to it. I think I'll play with it a bit, just for fun.

Correction

Posted Oct 25, 2007 5:03 UTC (Thu) by JoeBuck (guest, #2330) [Link] (1 responses)

The compiler does have at least some support for prototypes, so it isn't pure K&R C. Not sure what all is missing at this point.

Correction

Posted Oct 25, 2007 10:58 UTC (Thu) by nix (subscriber, #2304) [Link] 

A proper (tokenizing) preprocessor? Last time I looked at PCC it not only had a K&R-style
textual-transformation preprocessor, but its advocates were pushing this as a huge advantage.

An interesting historical artifact

Posted Oct 25, 2007 13:08 UTC (Thu) by Lev (guest, #41433) [Link] (15 responses) 

The claim is that it is now almost C99 compatible.
http://marc.info/?l=netbsd-tech-toolchain&m=118961767...
So your information appears to be out-of-date.

An interesting historical artifact

Posted Oct 25, 2007 13:57 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (14 responses) 

“some stuff is still missing, like the ability to do variable declarations anywhere”

I'm amused by the idea that these "thoroughly modern" Unix variants don't have anything in
their userspace that's been written since C9X made this mandatory.

"NetBSD, where history comes alive" ?

An interesting historical artifact

Posted Oct 25, 2007 15:01 UTC (Thu) by brinkmd (guest, #45122) [Link] (13 responses) 

Many modern programs are written with portability to old environments in mind.

An interesting historical artifact

Posted Oct 25, 2007 17:55 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (12 responses) 

Or, sometimes, are just written by old programmers who grew up in a K&R environment, so they
just always keep variable declarations at the start of a block, because it just feels ugly and
WRONG to have them strewn around intermixed with the code...  It almost makes me feel like I'm
writing C++ code! *shudder* ;-)

An interesting historical artifact

Posted Oct 26, 2007 3:13 UTC (Fri) by giraffedata (guest, #1954) [Link] (11 responses)

written by old programmers who grew up in a K&R environment, so they just always keep variable declarations at the start of a block,

Start of a block? The vast majority of C code I see keeps all the declarations at the start of the function.

An interesting historical artifact

Posted Oct 26, 2007 10:18 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (10 responses) 

> Start of a block? The vast majority of C code I see keeps all the
> declarations at the start of the function.

Which also happens to be the start of a block... ;-)  Yeah, true, most go at the start of the
function, but I at least can tolerate some inside other blocks, if they're only needed
there...  I can't tolerate them just spread willy-nilly throughout the code, though...  And, I
absolutely loathe declaring "int i" inside the parenthesis of a for() loop...  Whoever came up
with that one should be beaten... ;-)

Placement of variable declarations in C

Posted Oct 26, 2007 15:46 UTC (Fri) by giraffedata (guest, #1954) [Link] (9 responses)

I don't tolerate variables declared outside the scope in which they are used (and you should see how easy it is to move code around and split functions when you observe this rule). And I don't use the index variable of a for structure outside of the structure, so I saw the invention of the internally declared index as a great advancement. My blocks and functions are too short for anything to be spread willy-nilly throughout them.

Placement of variable declarations in C

Posted Oct 26, 2007 16:14 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (8 responses) 

> I don't tolerate variables declared outside the scope in which they are used

Sometimes, one uses the same variable in multiple blocks within a single function...

> And I don't use the index variable of a for structure outside of the structure,

You don't?  I often do...  Sometimes, when you break out of the loop, you need to know the
value of the index at that point for some reason or other (null terminate a string, obtain an
array count, etc.)...

> so I saw the invention of the internally declared index as a great advancement.

Bah, it's useless fluff...  Just declare one "int i;" at the top of the function, and use it
in ALL for() loops! ;-)  (Unless you need to nest multiple with differing indices, of course,
in which case you add an "int j;" to the top of the function as well... ;-))

Or, I could just be a grumpy old C coder, too set in his ways, too... ;-)

Placement of variable declarations in C

Posted Oct 26, 2007 16:47 UTC (Fri) by giraffedata (guest, #1954) [Link] (5 responses)

Sometimes, one uses the same variable in multiple blocks within a single function...

Then the scope in which it is used is the block that contains those blocks. Unless you're talking about reusing a C variable for multiple values, which is something else I don't tolerate.

And I don't use the index variable of a for structure outside of the structure,
You don't? I often do... Sometimes, when you break out of the loop, you need to know the value of the index at that point for some reason or other (null terminate a string, obtain an array count, etc.)...

I'm a structured programmer, so I never break out of a loop. In fact, I don't even recognize a for structure as a "loop." Structured programs don't branch.

Or, I could just be a grumpy old C coder, too set in his ways, too... ;-)

You sound like a very typical C coder; I'm unusual. C coders tend to be low-level coders; they write code which is a set of instructions to a computer. A variable is a storage location. Declarations get in your way. But I use C only grudgingly, in a careful paradigm to make it look like a high level language. High level code is a description of the solution to a computational problem. Its audience is a person, not a computer, and a compiler's job is create a low-level program that implements it. A variable is a symbol for a piece of information and the declarations are the heart of the code (indeed where most of my comments are).

Placement of variable declarations in C

Posted Oct 26, 2007 17:38 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (4 responses) 

> I'm a structured programmer, so I never break out of a loop.

So, all your loops are infinite, is that what you're saying?? ;-)

I was using "break out" not to ONLY mean using an explicit "break" statement, but also
naturally falling out due to failure of the test condition...  There are MANY cases where one
wants to use the loop index outside the loop, at least in my experience...

> In fact, I don't even recognize a for structure as a "loop." Structured
> programs don't branch.

*blink*  Ok, you're obviously using some strange definition of the term "structured" that I
wasn't previously aware of... ;-)  And, if you don't think a for() loop is a loop, WTF do you
think it IS??  It's certainly not a "structure", as you call it; a structure is a data record
created with the keyword "struct"... ;-)  In a for() loop, you LOOP over the same set of
statements multiple times until a condition is met, at which point you break out of that
loop...  If that's not a loop, I can't imagine what IS a loop, in your mind??

And, if your programs "don't branch", you must have a really hard time getting anything done,
forgoing if() statements, function calls, and all other such things, as you apparently have to
do... ;-)

The way I always understood the term, "structured programming" merely meant doing away with
the twisted spaghetti-code brought on by excessive goto use...  Eg: old-school BASIC code is
all unstructured, because you've got no other choose but goto for branching and control...
But, any time you're using something sane, like a loop, a conditional statement, or a function
call, that's structured...  Using goto or longjmp() is unstructured...

Placement of variable declarations in C

Posted Oct 28, 2007 2:16 UTC (Sun) by giraffedata (guest, #1954) [Link] (3 responses)

Structured programming isn't algorithmic programming that avoids excessive gotos. It's a different form of programming, and it doesn't have a goto concept at all.

Ideally, one would use a structured programming language for structured programming, but when forced to use C, one can use a paradigm that makes a structured meta-language out of it. For example, never use a goto statement.

You can look at a C program written in the structured paradigm as algorithmic and see looping and branching (obviously a compiler does), but since it wasn't written to be read that way, it won't be as easy to understand.

Structured programming has a for structure. It was named before C existed, and C's 'for' statement is meant to allude to it, though it is not the same as a structured for statement, e.g. in Pascal. The fact that the value of the index variable is predictable outside of the for statement is one way to tell the difference.

Besides algorithmic (branching and looping) and structured programming, there are various other forms of programming that don't have branches. LISP, Forth, and SAS are examples.

Placement of variable declarations in C

Posted Oct 28, 2007 11:28 UTC (Sun) by nix (subscriber, #2304) [Link] 

I don't know what your definition of `branching' is, but it's not anything 
I'm familiar with. In order to describe any version of Lisp as `not having 
branches' one would have to define the two branches of `if' as `not 
branches', and similarly for `cond'.

If an exception throw/catch isn't a `branch', I don't know what is.

Placement of variable declarations in C

Posted Oct 28, 2007 14:26 UTC (Sun) by RobSeace (subscriber, #4435) [Link] (1 responses) 

Yeah, what nix said...  I think you're just playing semantic games, here...  Just because you
don't want to call something a "branch" or a "loop", doesn't mean it doesn't fit the
definition of what I (and most other programmers I've encountered) use those words to mean...
Perhaps they mean something radically different in your world, I don't know...  Got a link to
any supporting documentation on your alternate meanings??

And, BTW, I happen to hold a degree in CS, so I'm fairly familiar with the various forms of
programming (though, it has been many years now), as well as languages such as LISP (which is
functional programming, BTW, and DOES have what *I* would call both loops and branches)...  I
just never encountered anyone who had your strange notions about structured programming, and
the supposed complete absense of "loops" and "branches", before... *shrug*

Placement of variable declarations in C

Posted Oct 28, 2007 19:04 UTC (Sun) by nix (subscriber, #2304) [Link] 

Well, it's more accurate to say that Lisp *can* be functional. You have to 
avoid most forms of `set'/`setf', though, and it's sort of tricky compared 
to the mixed functional/declarative approach generally adopted.

Placement of variable declarations in C

Posted Oct 27, 2007 15:58 UTC (Sat) by tjc (guest, #137) [Link] (1 responses)

Just declare one "int i;" at the top of the function, and use it in ALL for() loops! ;-)
If you're not too set in your ways you might want to try "int ii;" instead. I've been doing this for a few years, and while it looks odd at first, I got used to it. It's a lot easier to find "ii" in code; searching for "i" is futile.

(off-topic) Searching for variables

Posted Nov 18, 2008 18:40 UTC (Tue) by pjm (guest, #2080) [Link]

You would benefit a lot from learning regular expressions. If you use vim, then it suffices to type ‘*’ when the cursor is over an ‘i’ variable to find all occurrences of ‘i’ as a “word” (so excluding ‘if’ etc.).

Many IDEs go one step farther and allow searching for just the current variable as distinct from other variables & functions of the same name.

Incidentally, I hope that the original poster is joking (as the ‘;-)’ suggests) in the suggestion to use a shared variable for all temporaries. Such sharing makes it harder to modify one use of the variable because one needs to check whether subsequent code is using the resulting value.

Capitalization

Posted Oct 25, 2007 6:30 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses) 

Reading a whole article that carefully uses 'pcc' and 'GCC' capitalizations gets really tiring
on the eyes.  Just call them pcc and gcc, or perhaps PCC and GCC.

Capitalization

Posted Oct 25, 2007 7:41 UTC (Thu) by rsidd (subscriber, #2582) [Link] 

gcc is the GNU C Compiler binary. GCC is the GNU Compiler Collection.  So I think you make a
valid point: pcc may one day replace gcc on some systems, but will not replace GCC.

Mostly-Unfair Criticisms of GCC

Posted Oct 25, 2007 6:49 UTC (Thu) by rmathew (subscriber, #20961) [Link] (2 responses) 

(Disclaimer: I used to be a fringe contributor to GCC some time back.)

GCC is a compiler for multiple languages and for multiple platforms. It
can work as a native compiler, a cross compiler and even a crossed-native
compiler (See http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html
for the meaning of these terms). It is very difficult to quickly produce
good code under such conditions. Given that, it is amazing that it is
able to do what it does.

By its very nature, a production-quality compiler is a complex beast and
GCC is particularly complex. There are very few people qualified enough
to make significant changes to such software. Being paid to do so helps
considerably when you take the time and effort involved into account. It
is no wonder that the major contributors are employed by Red Hat, Code
Sourcery, Google, Apple, etc.

The GCC maintainers do not take a particular pleasure in removing support
for various architectures. As the compiler evolves, someone who cares
about an architecture needs to maintain the respective back-end and
regularly post the results of running the GCC test-suite to the
"gcc-testresults" mailing list (so that other maintainers can check the
health of GCC for such an architecture).

If there is no such visible proof of an architecture being maintained
and no responses to pleas of help on the GCC mailing lists to help
maintain the respective back-end, it is natural for the GCC maintainers
to assume that no one is interested in maintaining the back-end. Such a 
back-end needs to be removed to keep the code-base maintainable.

Even then, an architecture is first deprecated in a release (and an 
announcement made so that some one who cares can still offer some help)
and then removed in a subsequent release - this gives about two years
for some one who cares about the architecture to save it.

i386 is used by the vast majority of the users of GCC as well as the
companies that support GCC, so it is not surprising that it is in the
best shape. There is no conspiracy to turn it into a "commercial"
compiler with support only for i386.

Having said that, some of the criticisms are valid.

GCC is indeed getting more and more complex with each release, not
to mention slower and slower. As with any complex software, it is easier
to add new features or fix bugs that your customers care about than
spend time and effort refactoring it and making it faster (but amazingly,
such work still happens with GCC).

GCC is intentionally not "modular" with parts that can be cleanly
separated and used because RMS was afraid that nefarious people would
be able to use this to subvert the GPL. In fact, for the same reason,
he was opposed for some time to the idea of the Java compiler (GCJ)
being able to produce JVM byte-code. Fortunately, good sense prevailed.

As GCC adds more and more front-ends and back-ends, it becomes more and
more difficult to ensure that your patch does not break anything. The
GCC bootstrapping process and its regression suite takes longer and longer.
This raises the barrier for anyone contemplating to contribute to GCC.
Perhaps GCC should just go back to being a good C/C++ compiler.

Mostly-Unfair Criticisms of GCC

Posted Oct 25, 2007 9:28 UTC (Thu) by nix (subscriber, #2304) [Link] 

I thought that the Apple folks did some cachegrinding and found the problem to be largely
GC-related poor memory locality and a correspondingly awful rate of cache misses?

(IIRC this is being fixed by going back to obstacks in hot spots, but of course new
optimizations are landing at a rate of knots which is slowing everything right back down
again.)

Mostly-Unfair Criticisms of GCC

Posted Oct 26, 2007 17:50 UTC (Fri) by elanthis (guest, #6227) [Link] 

"GCC is intentionally not "modular" with parts that can be cleanly
separated and used because RMS was afraid that nefarious people would
be able to use this to subvert the GPL."

His usual nonsense that stops Free Software from actually being useful to more people.
Really, what is the point of Free Software if you go out of your way to make sure that people
can't use it?  You can't eliminate non-Free software if you constantly validate it by
artificially restricting the usefulness of Free Software.

It's especially silly since restricting GCC from being modular doesn't actually stop non-Free
software from using GCC as an intermediary.  If LLVM can add a backend to GCC, so can anyone
else, and a company could add a backend to generate some intermediary format and then process
that with their non-Free tools in a separate binary.  It would take some work, but if a
company really wanted a GCC front-end that badly, nothing in the world is stopping them.

fighting against an open source monopoly.

Posted Oct 25, 2007 9:03 UTC (Thu) by lmartelli (subscriber, #11755) [Link] (12 responses) 

Someone has to explain to me how is gcc a monopoly. 

It looks more like an open market to me: anybody can contribute, fork... Nobody was ever
forced to use gcc.

fighting against an open source monopoly.

Posted Oct 25, 2007 9:42 UTC (Thu) by DonDiego (guest, #24141) [Link] (7 responses) 

The right to fork allows building a program to compete with gcc out of gcc, but still somebody
has to sit down and *do* it.  For reasons that have been explained in the article and the
comments, this is far from easy.  Until then gcc remains a monopoly as it is the only viable
free compiler out there...

fighting against an open source monopoly.

Posted Oct 25, 2007 12:28 UTC (Thu) by dion (guest, #2764) [Link] (6 responses) 

I agree that you can say that GCC has a virtual monopoly on the Free compiler market (whatever
that is), but it's also important to note that there are none of the usual disadvantages of a
monopoly as the price is still quite fair and the barrier to entry for competition remains
low.

The only real complaint that someone might bring against a Free software monopoly is that a
mono culture is weaker against attacks.

For OpenSSH and OpenSSL those attacks are 0-day exploits, for GCC it could be patent suits.

fighting against an open source monopoly.

Posted Oct 25, 2007 16:19 UTC (Thu) by nix (subscriber, #2304) [Link] (5 responses) 

GCC doesn't do anything so unusual in the compiler world that pcc is likely to be
invulnerable.

(I mean, what'll they sue over? tree-ssa? GCC invention. SSA form? You'll find a GCC hacker's
name on the original paper, although he wasn't a GCC hacker then. But maybe they have a patent
on the concept of rendering a register allocator impossible to reimplement by means of heaps
of implicit dependencies ;} GCC would certainly be hit by *that* where the competition
wouldn't...)

fighting against an open source monopoly.

Posted Oct 25, 2007 17:29 UTC (Thu) by dion (guest, #2764) [Link] (1 responses) 

As far as I remember IBM has a patent on hierarchical menus, that they slapped SCO with in
their counter suit, so I wouldn't be too surprised if someone turns out to have an equally
basic patent on compiler construction.

fighting against an open source monopoly.

Posted Oct 26, 2007 10:26 UTC (Fri) by nix (subscriber, #2304) [Link] 

Compilers are old enough that the really basic stuff should have expired (*if* someone didn't
re-patent it, which would of course be an invalid patent, not that that stopped anyone
before).

fighting against an open source monopoly.

Posted Oct 25, 2007 18:03 UTC (Thu) by bboissin (subscriber, #29506) [Link] (2 responses) 

Some regalloc and out-of-SSA algorithms are already patented.

fighting against an open source monopoly.

Posted Oct 25, 2007 21:27 UTC (Thu) by nix (subscriber, #2304) [Link] 

Oh yes, register allocation and graph colouring is a patent minefield, but 
hopefully IBM is helping there...

fighting against an open source monopoly.

Posted Oct 31, 2007 19:36 UTC (Wed) by jzbiciak (guest, #5246) [Link] 

As are certain instruction scheduling techniques, such as various techniques in and around
software pipelining, predicated (conditional execution) and so on.  These techniques are
important to superscalar processors, especially (but not certainly not limited to) VLIW / EPIC
style processors.  

(Full disclosure:  I'm named an inventor on two such issued patents.  Take that as you will.)

fighting against an open source monopoly.

Posted Oct 25, 2007 18:19 UTC (Thu) by southey (guest, #9466) [Link] (1 responses) 

Can you compile the Linux kernel with another compiler other than GCC?
Do you have binary compatibility between compilers especially for C++? 

(The answers were no for earlier versions of Intel's C/C++ compiler.)

Depending on what you define as a monopoly, an answer of no to either question indicates some
characteristics of a monopoly is present.

fighting against an open source monopoly.

Posted Oct 25, 2007 21:54 UTC (Thu) by nix (subscriber, #2304) [Link] 

It's nearly impossible to write an OS kernel using only portable C, and 
the Intel C compiler actually pretends to *be* GCC and implements a lot of 
GCC extensions in part so that it can compile the kernel.

As for C++ compatibility, I thought the Intel compiler conformed to the 
same (originally Itanium) C++ ABI as GCC, HP C++, and others do: there 
have of course been bugs in this conformance, but that hardly makes a 
monopoly.

fighting against an open source monopoly.

Posted Oct 26, 2007 11:15 UTC (Fri) by jospoortvliet (guest, #33164) [Link] 

Of course you're right, a FOSS monopoly is nothing like a normal one. 
What Theo meant is there aren't many alternatives (if any) which leads to 
less pressure on the project, and subsequently to possibly worse code.

Look at KDE/Gnome - sure, duplication of efforts, but also sharing of 
ideas and competition/coopetition - which is good for both. GCC could 
probably use a competitor/coopetitor, which is the point he makes.

fighting against an open source monopoly.

Posted Nov 1, 2007 16:44 UTC (Thu) by dkite (guest, #4577) [Link] 

Yes, and we could all use Wordperfect and Firefox too.

Think defacto monopoly.

Derek

OpenBSD not the only ones grumbling about gcc

Posted Oct 25, 2007 20:30 UTC (Thu) by rfunk (subscriber, #4054) [Link] (3 responses)

Linux kernel developers are unhappy with gcc too.

Linux developers have love/hate relationship with gcc

Posted Oct 25, 2007 21:50 UTC (Thu) by khim (subscriber, #9252) [Link]

For example they refused for a looong time to switch from gcc 2.7.2.x to gcc 2.95 and later to gcc 3.x - yet today they happily abandoned gcc 2.95 because it's "too buggy". They like bugfixes in gcc (when it makes life easier for kernel developers) but they hate to fix bugs in kernel (when new gcc produces incorrect code because it uses more aggressive optimizations) - it all is quite natural. Yet they are not insane enough to try to port Linux kernel to anything else - because they need portable free compiler which generates fast code and that currently means gcc...

OpenBSD not the only ones grumbling about gcc

Posted Oct 25, 2007 22:19 UTC (Thu) by sayler (guest, #3164) [Link] (1 responses) 

Not only that.. in some sense I think it would be fair to state that for things like the Linux
kernel, some of GCC's more adventurous optimizations are really damaging.  (See above thread
for details).

In general, the kernel is probably fairly well-served by a "glorified assembly" C compiler,
whereas gcc has a much broader target.  A C-only compiler that did simple intra-procedure
optimization at 10x the speed of GCC might be a win.

OpenBSD not the only ones grumbling about gcc

Posted Oct 25, 2007 23:37 UTC (Thu) by nix (subscriber, #2304) [Link] 

I don't see why a sort of -O0.5 variant that dikes out 80% of GCC's 
optimization passes wouldn't be doable, or maybe even -Okernel that dikes 
out just the ones the kernel hackers dislike. The passes mechanism should 
be able to do that without especially much difficulty (modulo the existing 
problem where some of them don't properly declare their dependencies on 
earlier/later passes).

I think I have a project for this weekend... ;}

A potential competitor for GCC: pcc

Posted Oct 25, 2007 22:31 UTC (Thu) by man_ls (guest, #15091) [Link]

de Raadt is right to be concerned about monopolies, free software or otherwise.
Why exactly? Monopolies are not bad per se; abuse of a monopoly is. If someone remains the sole provider of some good because they have the best service and the best prices around, its monopoly can even have good consequences (because this provider does not need to spend efforts in competition). Google's near monopoly on web search can be obnoxious, but it is hardly bad for people.

On the other hand, monocultures are usually considered as a bad thing, since they lead to poorer environments. Maybe that is what the author meant?

A potential competitor for GCC: pcc

Posted Oct 29, 2007 8:40 UTC (Mon) by hippy (subscriber, #1488) [Link] (1 responses) 

It is shame that the TenDRA compiler does not get more interest (http://www.tendra.org/). It
is BSD licensed, multi-platform and multi-language. It's intermediate format is based on ANDF
(http://en.wikipedia.org/wiki/ANDF). It was a brilliant idea that was released as open source
just too late to make a difference. 

One of the main aims of TenDRA was to enable the distribution of applications and libraries in
the intermediate format. The intension was to have 'installers' on each target platform that
could compile the portable intermediate format into the target op-code. This would enable a
single 'compiled' distribution of applications for all platforms that had a TenDRA installer.

(I declare an interest, I worked on the original TenDRA team at the UK Defence Evaluation and
Research Agency in Malvern).

Richard

A potential competitor for GCC: pcc

Posted Oct 30, 2007 23:51 UTC (Tue) by bfeeney (guest, #6855) [Link]

Interestingly, that sounds a lot like LLVM, which is more likely to replace GCC (thanks to the clang front-end) than GCC. Frontends (like clang) generate their intermediate representation in LLVMs very low-level intermediate representation and then they have a choice

  1. They can use the rest of the toolchain to generate native code for a particular platform, which they distribute or
  2. They can assemble the IR objects into a bundle (I have to admit to not knowing a great deal about the specifics of this) which they then distribute. Users with a properly configured environment with LLVM installed will have that converted to native code using a JIT like Java.

I think it's possible to IR compiled on the host platform as well - certainly it wouldn't be particularly difficult.

To be honest, I find the *BSD's fascination with PCC to be a bit odd - the main reason it's so fast is because it does so little, applications generated by it certainly won't be faster than their GCC equivalents for some time to come. LLVM and clang, on the other hand, offer good performance now, and are jointly distributed under a BSD licence, with clang getting significant support from Apple. I think it would be worth their while trying to partake, and therby control the direction of, clang development rather than start almost from scratch with PCC.

gcc is a skyscraper

Posted Nov 1, 2007 10:40 UTC (Thu) by jfj (guest, #37917) [Link] (3 responses) 

It is no little program!

gcc is probably bigger than linux. Sure linux has more lines of code but most of that is
device drivers, so a user at a given time only uses about 5% of the total of the kernel.

Also, the kernel's job is to talk to the hardware. The job of a compiler is to find the
optimal machine code representation of a C (C++, etc) program. This is a rather unsolvable
problem and it is simply constantly improved over the years.

It would be probably easier to write an operating system better than linux/BSD than a compiler
better then gcc.

OK. Some times gcc devs are too concerned with the SPEC benchmarks (which is a red herring
imho), but at least they believe in free software.

gcc is a skyscraper

Posted Nov 1, 2007 21:16 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses) 

The SPEC benchmarks are only benchmarks, but *sudden worsenings* in SPEC 
output are a good clue that something's just been broken. It's also useful 
to keep an eye on C compilation speed (bootstrap-and-test time is also 
somewhat useful, but the compiler and testsuite are growing, so that is 
expected to rise even if the compiler got no slower).

gcc is a skyscraper

Posted Nov 2, 2007 11:45 UTC (Fri) by jfj (guest, #37917) [Link] (1 responses) 

Yes. But take for example, auto-vectorization. icc does it and it gets some amazing results in
SPEC. But the fact is that *any real program that really cares about speed cannot depend on
the compiler to auto-vectorize*; its developers will provide custom assembly with MMX for the
critical parts.  Now that is a red herring. Maybe LTO as well.

Also, I suspect that commercial compilers spend a lot of effort to look good in SPEC. Maybe
they even identify those benchmark programs and generate predefined assembly, I don't know :)

I generally think that timings on real programs is far more useful. There could be a testsuite
that runs some timings on bzip, gzip, ffmpeg encoding/decoding, etc. SPEC's little programs
are to sensitive to small changes.

Finally, I think that open source would benefit more from new gcc extensions and special
attributes.

gcc is a skyscraper

Posted Nov 2, 2007 13:04 UTC (Fri) by nix (subscriber, #2304) [Link] 

LTO definitely isn't a red herring: most programs consist of more than one 
object file and can't easily use --combine (which is far too memory hungry 
to be useful anyway: I tried compiling GCC 4.2.1 with --combine and it ran 
my 1.5Gb Athlon out of memory...)

Attitude of the gcc maintainers (a rant)

Posted Nov 1, 2007 16:02 UTC (Thu) by anton (subscriber, #25547) [Link] (2 responses)

I am a maintainer of a GNU package (gforth) that depends on GNU C extensions, and I am pretty unhappy with the attitude of the gcc maintainers since about gcc-3.x, which I perceive to be: if your program is not 100% pure ANSI C, the program is buggy, and bug reports coming from their maintainers them will not be taken very seriously. I.e., real-world programs need not apply; exceptions may be granted for SPEC benchmarks and maybe the Linux kernel.

The problems we have with gcc are the pessimization of indirect gotos, and the reordering of blocks even with the -fno-reorder-blocks flag, all new since gcc-3.x. These make threaded code slow (typically by a factor of 2) and, if we cannot find workarounds, make it impossible to apply code-copying techniques such as dynamic superinstructions (another factor of 2). These techniques are used in a number of interpreters and binary translators, such as Qemu, SableVM, Gforth, YAP and Sicstus Prolog.

Here are some Gforth benchmark timings that show the effect of these problems (times in seconds CPU time): 

Athlon 64 X2 4400+ (2.2GHz):
sieve bubble matrix  fib
 0.184 0.296  0.128 0.304 gforth-0.6.2 gcc-2.95.1 IA-32
 0.384 0.668  0.808 0.580 Debian gforth-0.6.2-7.2 Debian gcc-4.1.1-20 AMD64

Pentium 4 2.26GHz:
sieve bubble matrix  fib
 0.231 0.288  0.184 0.342 gforth-0.6.2 gcc-2.95.1 IA-32
 0.510 0.846  1.010 0.658 Debian gforth-0.6.2-4 Debian gcc-3.3.3 IA-32
So, a slowdown by a factor of up to 6.3 (matrix on the Athlon 64 X2) due to "progress" in gcc.

We have been writing bug reports about these things for quite some time, resulting in slow progress, but at the same time, new issues came up. However, the GCC maintainers declared my latest bug report invalid in less time than it took me to prepare it, thus making sure that this was my last gcc bug report (I don't like to waste my time).

You can find more discussions of this situation (with participation of a gcc maintainer) in this thread.

Given the attitude of the gcc maintainers, I would very much like to have alternatives to gcc. The direct benefit would be to use the alternative compiler, a possible indirect benefit would the the readjustment of the gcc maintainer's attitude.

Attitude of the gcc maintainers (a rant)

Posted Nov 1, 2007 21:25 UTC (Thu) by nix (subscriber, #2304) [Link] 

Ah, you've been Pinskied. Andrew has a *interesting* attitude to WONTFIX 
and being short with bug reporters which is not shared by many other GCC 
maintainers.

FWIW if you bring it up with other GCC maintainers they are very likely to 
be more reasonable: there was an article in the most recent GCC Summit 
proceedings about speeding up {in,}direct-threaded interpreters.

(just an observer, just my opinion, real GCC maintainers read this site 
and are welcome to call me an idiot if they wish)

Attitude of the gcc maintainers (a rant)

Posted Nov 17, 2008 17:51 UTC (Mon) by cjcoats (guest, #9833) [Link]

As a (mostly Linux-based) Fortran developer, I've seen this too -- particularly parsing command-line options in a manner that imitates the worst of pre-90 FORTRAN -- fixed-source-form Fortran is the _only_ other language I know that regards whitespace as insignificant (the first step in processing it is to eat whitespace before any other parsing).

But "-o penmp" and "-openmp" mean the same thing for gfortran -- and two out of three Linux distros don't have the docs on-line to tell you what they *really*do* want. ;-( And if you complain about that, you get abuse, also.

fwiw.


Copyright © 2007, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds