LWN: Comments on "pcc seeks contributions to reach 1.0 milestone"

pcc seeks contributions to reach 1.0 milestone

nix — Fri, 05 Dec 2008 00:44:44 +0000

Oh yes, agreed. I was being pedantic in another area, that it makes no
sense to say that you use SSA *as* your IR, because it's not an IR, just a
set of rules that constrain that IR (it's applicable to many different
sorts of IR, but *you* know that.)

pcc seeks contributions to reach 1.0 milestone

salimma — Thu, 04 Dec 2008 17:15:53 +0000

LLVM IR is almost entirely in SSA form -- it still has pointers, but apart from that, assignments must be to fresh "registers"

pcc seeks contributions to reach 1.0 milestone

nix — Thu, 20 Nov 2008 22:36:10 +0000

I only just learned of libfirm from this thread, and it looks *deeply*
cool. I can think of half a dozen potential uses for it already :)

pcc seeks contributions to reach 1.0 milestone

bboissin — Thu, 20 Nov 2008 16:49:14 +0000

"you'd need to go through another one immediately before conversion to assembler or your output would be ludicrously inefficient"

Coalescing is done during the Out-of-SSA pass (and it would be very inneficient to do the Out-of-SSA by replacing each phi with a move), if you're in CSSA form, just replace every phi-related variable with a unique variable and that's all (so the hard part is the conversion to CSSA).

As for the IR, I believe SSA can really influence your IR, so it's not just a property (you need parallel moves, etc). Libfirm does that very nicely from what I've seen.

BSD Dissatisfied with gcc... why?

etienne_lorrain@yahoo.fr — Thu, 20 Nov 2008 10:34:34 +0000

> > the basic use of volatile (register mapped) integers
> Wrong. I think you were thinking of the "register" keyword.

No, I was and am still talking of "volatile".
The problem is that the C++ standard treats all attributes the same way, and gives examples with "const".
I do understand that to overwrite the "const" attribute, I need to do a dirty cast to non-const, but the basic use of volatile is to copy them into standard variables, at a controled place of the software:

volatile unsigned ethernet_status;
/* -> address of ethernet_status defined in the linker file */
int fct(void) {
unsigned status = ethernet_status; // single read of "ethernet_status"
return ((status & 1) || ((status & 2) ^ (status & 4)));
}

Now tell me how to put ethernet_status and fct() into a class and compile without warning and without casting ethernet_status to non-volatile...

But the worst for me is still considering a volatile structure of bitfields as a structure of volatile bitfields, even if I see no problem to consider a constant structure of bitfields as a structure of constant bitfields...
For instance:
volatile struct color_s { char red, green, blue, transparent; } volcolor;
int fct (void) {
struct color_s color = volcolor;
return color.red == color.blue;
}
Because volcolor is considered as a structure of volatile fields, volcolor is read twice (two byte access) when optimising.

pcc seeks contributions to reach 1.0 milestone

nix — Thu, 20 Nov 2008 07:51:42 +0000

I'm fairly sure 'having SSA as your primary IR' makes no real sense: it's
like saying 'having assignment as your primary IR'. Having your primary
IR, *whatever it is*, be in SSA form for as much of the time as possible
is probably a very good thing (although I'm not sure how you could convert
*directly* to it: you'd need to go through a non-SSA form immediately
after parsing, and you'd need to go through another one immediately before
conversion to assembler or your output would be ludicrously inefficient).

pcc seeks contributions to reach 1.0 milestone

bboissin — Thu, 20 Nov 2008 00:16:34 +0000

You should really consider having SSA as your primary IR. It makes so many things trivial... I especially like the IR used by libfirm (http://www.info.uni-karlsruhe.de/software/libfirm/index.p... ). It gives you many things for free (SSA all along, no dead code, etc.)

BSD Dissatisfied with gcc... why?

nix — Wed, 19 Nov 2008 20:57:39 +0000

In particular, 'volatile' is still useful. 'register' is, basically, not,
with the single rare exception of global register variables (a GCC
extension).

pcc seeks contributions to reach 1.0 milestone

nix — Wed, 19 Nov 2008 20:46:04 +0000

Just... just... just forget everything I've posted for the last week.
Nearly all of it seems to be wrong. Posting when ill or when sickening up
for something seems to turn me into a babbling idiot incapable of adding
two and two without getting NaN.

BSD Dissatisfied with gcc... why?

dgm — Wed, 19 Nov 2008 14:36:36 +0000

> the basic use of volatile (register mapped) integers

Wrong. I think you were thinking of the "register" keyword.
"Volatile" means that the contents of a variable can be changed externally at any time. Think, for instance, of a memory mapped hardware register. Basically it instructs the compiler to avoid certain optimizations based on knowledge of the previous value, and forces it to read it every time.

pcc seeks contributions to reach 1.0 milestone

ragge — Wed, 19 Nov 2008 11:10:10 +0000

And that opinion is based on... on what?

pcc seeks contributions to reach 1.0 milestone

nix — Wed, 19 Nov 2008 08:36:51 +0000

I think I must be getting it from the wrong place. Never. Do. Research.
While. Ill. *slaps self*

pcc has been making good progress

ragge — Wed, 19 Nov 2008 08:36:36 +0000

Well, there were some maybe not so good design decisions in the compiler, but those that matters has been corrected. Hey, it's a small compiler, not so difficult to fix things :-)

pcc seeks contributions to reach 1.0 milestone

ragge — Wed, 19 Nov 2008 07:34:28 +0000

Hm, which compiler did you look at? :-) The SSA conversion code has been into pcc for years, I just haven't finished it up, it has not been my main priority.

If you have a compiler with a reasonable internal design, none of the standard optimizing algorithms are especially difficult to add (like SSA conversion, graph-coloring register allocator, strength reduction etc.)

Good link

ragge — Wed, 19 Nov 2008 07:28:12 +0000

Please look at the presentation again. The things you mentions are already put in the compiler. The initial design of the compiler made it very easy to add state-of-the-art optimizing stuff. I think especially the multi-class register allocator is one of the best available today.

Currently the code generated is between 0-10% slower than code generated by gcc, and most of the time "lost" is due to not-yet added optimizations. Still, the compiler runs around 15 times faster than gcc.

Nice example...

dlang — Tue, 18 Nov 2008 19:07:22 +0000

multi-threaded programming will be in much better shape (standards wise) in a couple years.

defining this area is one of the bigger changes in the new POSIX, C, and C++ standards that are nearing completion (POSIX is complete, C is expected next year, C++ sometime after that)

Nice example...

jzbiciak — Tue, 18 Nov 2008 17:38:59 +0000

I don't come down on the side of "GCC == BAD" at all. What I was pointing out, though, is that the C standard and its wiggle room are at odds with things like kernels and multithreaded programs. If you can only rely on what the C standard guarantees, then it's much harder to do useful things efficiently.

More aggressive optimizations will rely on this wiggle room and sometimes break things. That's a headache for kernel developers. Sure, GCC may get fixed, but breaking to begin with was an annoyance. If the break causes subtle problems, diagnosing the issue could be very difficult.

This is where a simpler compiler can be more effective. If it provides very simple semantics (rather than the extraordinary wiggle room the standard provides), it becomes easier to reason about the correctness of the program. Yes, it's less portable to other compilers, but as long as the compiler itself is portable, what's the issue?

After all, you don't see many Linux builds that don't use GCC (although there are a few...).

Nice example...

daney — Tue, 18 Nov 2008 17:24:01 +0000

That is an excellent example, one that clearly shows that the GCC developers being responsive by carefully analysing the situation and changing their compiler to address the concerns raised by the Linux kernel developers.

There was some initial contention, but once the situation was well understood, the desired results were obtained. There are some who argue based on the axiom that GCC == BAD, but I don't think it holds in the case you mention.

Good link

nix — Tue, 18 Nov 2008 16:03:59 +0000

The *very* early C compilers are even more stunningly simple, and they
probably work quite well for PDP10s, and are good examples even now of
simple parsers.

But if you want to get decent performance on modern hardware you *need*
things like speculative code motion (to avoid pipeline stalls), and if you
want that then you need dataflow analysis and I can see no way they can do
that with PCC without turning it into something quite different.

So perhaps they plan for this to stay forever in the ghetto of 1980s and
pre-1980s hardware? I'm not sure, but it hardly seems like an exciting
growth area to me.

pcc seeks contributions to reach 1.0 milestone

nix — Tue, 18 Nov 2008 16:00:06 +0000

Good grief. I had no idea pcc was *that* primitive. They will hit a wall
as hard as carborundum as soon as they try to do decent optimizations.
(Why? Look at the IR. Try to figure out how to rewrite the thing into SSA
form without significant agony. I gave up. And without SSA, you lose, oh,
pretty much all high-level optimizations described in the literature. It's
one reason why GCC was held back for so long... and now another compiler
is blithely heading off down the same wrong track. *sigh*)

BSD Dissatisfied with gcc... why?

nix — Tue, 18 Nov 2008 15:10:19 +0000

OK, right, my memory is flawed and I shouldn't post while high on
gamma-globulins.

BSD Dissatisfied with gcc... why?

etienne_lorrain@yahoo.fr — Tue, 18 Nov 2008 10:42:45 +0000

> Not following standards is a very slippery path.

Even when the standards are very unclear, like volatile structure of bitfields considered by GCC (in C) as structure of volatile bitfields, resulting in reads of volatiles on an "C" whole structure write?
Moreover, I still do not understand how in C++ I am supposed to use volatile integers - when I want to write a non volatile integer to it or read it into a non volatile integer - i.e. the basic use of volatile (register mapped) integers. Obviously I do not want warnings or a cast of my volatile register mapped integer into non volatile...

BSD Dissatisfied with gcc... why?

dgm — Tue, 18 Nov 2008 08:18:20 +0000

To disprove yourself, simply try LCC or other simple compiler, and watch the code run 2 or 3 times slower than the one generated by GCC (that is in turn two times slower than the one generated by other compilers).

The real problem with GCC is that it's overly complex (and slow) for the quality of optimizations it provides.

Good link

roskegg — Tue, 18 Nov 2008 07:59:43 +0000

Ragge's presentation that you linked to was really nifty. I didn't realize a C compiler could be so simple.

I hope he finishes pdp10 support at some point, and that NetBSD and OpenBSD get ported to the PDP10. It would be a fun honeypot to leave running.

pcc seeks contributions to reach 1.0 milestone

RandyBolton — Tue, 18 Nov 2008 03:55:49 +0000

I found this recent presentation from Anders Magnusson on the web that gives a good overview of the current state of PCC:

Bringing PCC into The 21th century
by Anders Magnusson
October 11, 2008
http://www.nycbsdcon.org/2008/files/magnusson_pcc.pdf

BSD Dissatisfied with gcc... why?

jzbiciak — Tue, 18 Nov 2008 01:49:54 +0000

Granted, since I follow Linux much, much more closely than BSD, I tend to hear it from the Linux kernel guys. Here's a thread that captures what I'm talking about.

pcc has been making good progress

robert_s — Tue, 18 Nov 2008 00:53:02 +0000

"Someone here said pcc suffers from ancient bad design decisions. What would those be? The codebase is almost entirely new, very little of the original code remains."

Exactly - so they're essentially scratchwriting a compiler, it's just everyone's afraid of saying that for some reason. Perhaps because it betrays the mammoth nature of the task.

Relying on Caldera?

JoeBuck — Tue, 18 Nov 2008 00:50:40 +0000

Oh, please. The press releases from Caldera announcing the source code release are on the record, and you can find them on the web. There was never any restriction on commercial use.

Here's a copy of the announcement, which for some odd reason you'll no longer find on SCO's site.

Given subsequent events, perhaps SCO can argue that their predecessor company had no right to do this, because Novell, not they, own Unix. But to say so would undercut their own argument in their legal troubles with Novell.

BSD Dissatisfied with gcc... why?

qg6te2 — Tue, 18 Nov 2008 00:42:13 +0000

it seems like nearly every major GCC release seems to break something subtly somewhere that was relying on a stronger guarantee than is offered by the standard.

"Stronger guarantee than offered by the standard"? I don't think such a thing exists. Not following standards is a very slippery path. If one writes code that does not follow the standard but rather some bastardised version of it, the resulting code is by default non-portable and likely to break across compilers (even on the same architecture). I've seen non-portable trickery where the entire point was to get a 5% speedup on a particular version of a compiler.

BSD Dissatisfied with gcc... why?

dlang — Tue, 18 Nov 2008 00:33:45 +0000

the fact that chips have been getting _much_ smarter and changing their internal architecture has meant that a lot of the optimizations that GCC tries so hard to do are not as useful as they used to be (and in some cases activly bad for current hardware).

this makes a simple compiler very attractive (at least in theory)

BSD Dissatisfied with gcc... why?

EmbeddedLinuxGuy — Tue, 18 Nov 2008 00:33:44 +0000

the stated reason for pcc's being revived in the first place rather than working on something non-stoneage was a fear of the GPL / desire to have absolutely nothing GPLed in their entire distro.

What I have read from the BSD leadership explicitly denies this. See the interview in the Jem Report where Theo de Raadt says that replacing GPL-licensed code has "never really been the agenda". I don't deny that there may be BSD folks who would prefer an all-BSD-licensed distribution, but I have not seen this stated as a reason for anything.

Theo's point is that we should not be dependent on a software monoculture; which is the same reason we benefit from both KDE and GNOME, Linux and BSD, Firefox and Webkit, etc etc. I see nothing "anti-GPL" here.

pcc seeks contributions to reach 1.0 milestone

jzbiciak — Mon, 17 Nov 2008 23:55:59 +0000

Well, its license is very BSD-like. It's certainly not GPL.

BSD Dissatisfied with gcc... why?

jzbiciak — Mon, 17 Nov 2008 23:55:05 +0000

If GCC's GPL license were the driving issue, then why not contribute to LLVM's Clang and get a thoroughly modern compiler with a very BSD-like license? PCC dates to the 70s and GCC to the 80s.

LLVM's license reads an awful lot like the BSD-with-advertising-clause, just with UIUC's name subbed in.

http://llvm.org/releases/2.3/LICENSE.TXT

I suspect it's not just license.

I seem to recall a big part of the attractiveness of PCC was that it was very simple and fast. Advanced transformations and optimizations have greater likelihood of breaking a complex program. Aggressive optimizations push the semantics of the C language quite a bit, such that it's hard to write something like a kernel. Lately, it seems like nearly every major GCC release seems to break something subtly somewhere that was relying on a stronger guarantee than is offered by the standard.

BSD Dissatisfied with gcc... why?

nix — Mon, 17 Nov 2008 22:54:56 +0000

They're not incompatible, but the stated reason for pcc's being revived in
the first place rather than working on something non-stoneage was a fear
of the GPL / desire to have absolutely nothing GPLed in their entire
distro.

I consider this utter lunacy, but if they want to waste their time to that
extent, well, it's their time to waste.

BSD Dissatisfied with gcc... why?

DonDiego — Mon, 17 Nov 2008 22:29:35 +0000

It's not just BSD folks. gcc gets slower with every release, the code is generates is often of poor quality and bug reports are sometimes brushed aside and ignored.

BSD Dissatisfied with gcc... why?

EmbeddedLinuxGuy — Mon, 17 Nov 2008 22:14:37 +0000

Thanks for reminding me of the licensing incompatibility

If you are implying that GPL and BSD licenses are incompatible, this is not accurate. Of course they are compatible; how do you think the project has gotten by so far?

pcc seeks contributions to reach 1.0 milestone

nix — Mon, 17 Nov 2008 22:12:23 +0000

But LLVM has the Wrong License, sigh.

pcc has been making good progress

roskegg — Mon, 17 Nov 2008 21:57:45 +0000

I've been watching the commits to the pcc tree, and am really impressed at the progress it is making. It really is fitting the bill of small, clean, fast, portable. Just recently support for inline functions was added.

The pcc project is small enough that a regular guy can wrap his head around it, whereas gcc takes a lot of effort.

Ragge deserves our support, and we can only benefit from pcc become better. It is already usable.

Someone here said pcc suffers from ancient bad design decisions. What would those be? The codebase is almost entirely new, very little of the original code remains.

Relying on Caldera?

dmarti — Mon, 17 Nov 2008 21:06:24 +0000

After Caldera became SCO, the company denied that it ever released "ancient Unix" for anything but "non-commercial use." Does anyone have a clear committment from Novell or any of the other Unix copyright holders to release this? Or are people relying on the 2002 letter from Bill Broderick?

pcc seeks contributions to reach 1.0 milestone

robert_s — Mon, 17 Nov 2008 20:03:45 +0000

Total waste of time (and now money). Time would be better spent working on Clang for LLVM. The only thing they can possibly inherit from pcc is poor design decisions.