«

http://slashdot.org/

"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."

The PCC was the first C compiler I used and studied, back then, when
Unix and C started appearing here in France. We had a source license,
and browsing there I found the PCC code.

The discussion is here.

http://undeadly.org/cgi?action=artic...mode=expanded/

It is interesting to see the level of frustration of the BSD people
with GCC. They just want a compiler that is simple, small, and...
supports all architectures that Open BSD supports.

Will they succeed?

Of course it is easy to have a compiler that supports 3 back ends, say.
But supporting 10?

With a mixture of weird CPUs etc?

In any case PCC should be up to the task. I remember it run in the
Honeywell-Bull computers of that time (beginning of the 80s), so
it should run in many others... Running with those was really a
challenge.

On Sep 17, 2:53 pm, jacob navia <ja...@jacob.remcomp.fr> wrote:
> http://slashdot.org/
>
> "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."
>
> The PCC was the first C compiler I used and studied, back then, when
> Unix and C started appearing here in France. We had a source license,
> and browsing there I found the PCC code.
>
> The discussion is here.
>
> http://undeadly.org/cgi?action=artic...mode=expanded/
>
> It is interesting to see the level of frustration of the BSD people
> with GCC. They just want a compiler that is simple, small, and...
> supports all architectures that Open BSD supports.
>
> Will they succeed?
>
> Of course it is easy to have a compiler that supports 3 back ends, say.
> But supporting 10?
>
> With a mixture of weird CPUs etc?
>
> In any case PCC should be up to the task. I remember it run in the
> Honeywell-Bull computers of that time (beginning of the 80s), so
> it should run in many others... Running with those was really a
> challenge.

Starting with PCC and trying to compete with GCC is like starting with
a dingy and planning to race a 65' yacht.

I guess that :
http://www.tendra.org/about/

has a much better chance to succeed.

Other attempts:
http://www.thefreecountry.com/compilers/cpp.shtml

user923005 <> wrote:
> On Sep 17, 2:53 pm, jacob navia <ja...@jacob.remcomp.fr> wrote:
>> http://slashdot.org/
>>
>> "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."
>>
>> The PCC was the first C compiler I used and studied, back then, when
>> Unix and C started appearing here in France. We had a source license,
>> and browsing there I found the PCC code.
>>
>> The discussion is here.
>>
>> http://undeadly.org/cgi?action=artic...mode=expanded/
>>
>> It is interesting to see the level of frustration of the BSD people
>> with GCC. They just want a compiler that is simple, small, and...
>> supports all architectures that Open BSD supports.
>>
>> Will they succeed?
>>
>> Of course it is easy to have a compiler that supports 3 back ends, say.
>> But supporting 10?
>>
>> With a mixture of weird CPUs etc?
>>
>> In any case PCC should be up to the task. I remember it run in the
>> Honeywell-Bull computers of that time (beginning of the 80s), so
>> it should run in many others... Running with those was really a
>> challenge.
>
> Starting with PCC and trying to compete with GCC is like starting with
> a dingy and planning to race a 65' yacht.

That depends on in what manner you are trying to compete. It is true that it
seems unlikely that PCC will be able to generate as good code as GCC anytime
in the near future. On the other hand it should not be very difficult to
compete with GCC with regards to compile time and memory usage needed by the
compiler (areas in which GCC is not very good.)

For people trying to do development on older machines these features can be worth
much more than having the generated code run 0.5% faster.

Other people will have other priorities.



>
> I guess that :
> http://www.tendra.org/about/
>
> has a much better chance to succeed.
>
> Other attempts:
> http://www.thefreecountry.com/compilers/cpp.shtml
>

--
<Insert your favourite quote here.>
Erik Trulsson

Erik Trulsson wrote:

> That depends on in what manner you are trying to compete. It is true that
> it seems unlikely that PCC will be able to generate as good code as GCC
> anytime in the near future. Â*On the other hand it should not be very
> difficult to compete with GCC with regards to compile time and memory
> usage needed by the compiler (areas in which GCC is not very good.)

Properties such as compile time and memory usage are only relevant to the
compilation process, which is a very tiny part of the whole software
production process. As far as compilers go and what is expected from the
compiler, those features may be nice to have but they are very far from
being important. In fact, they are totally irrelevant.

No one in their right mind prefers a lighter compiler that produces weak or
buggy code to one which is not so light but produces strong, tight and even
secure code.


> For people trying to do development on older machines these features can
> be worth much more than having the generated code run 0.5% faster.

In this day and age anyone can purchase a very capable system with
multi-core processors for less than 300 euros. It is also possible to buy
used systems for almost nothing. Frankly, I don't believe that build times
are an issue anymore or have been for some time.

> Other people will have other priorities.

I don't believe that any developer will ever be willing to trade quality
code for a snappier build process. Naturally it is a nice feature but there
is absolutely no way it would ever be seriously considered for any
tradeoff.


Rui Maciel

Erik Trulsson wrote:

> That depends on in what manner you are trying to compete. It is true that
> it seems unlikely that PCC will be able to generate as good code as GCC
> anytime in the near future. Â*On the other hand it should not be very
> difficult to compete with GCC with regards to compile time and memory
> usage needed by the compiler (areas in which GCC is not very good.)

Properties such as compile time and memory usage are only relevant to the
compilation process, which is a very tiny part of the whole software
production process. As far as compilers go and what is expected from the
compiler, those features may be nice to have but they are very far from
being important. In fact, they are totally irrelevant.

No one in their right mind prefers a lighter compiler that produces weak or
buggy code to one which is not so light but produces strong, tight and even
secure code.


> For people trying to do development on older machines these features can
> be worth much more than having the generated code run 0.5% faster.

In this day and age anyone can purchase a very capable system with
multi-core processors for less than 300 euros. It is also possible to buy
used systems for almost nothing. Frankly, I don't believe that build times
are an issue anymore or have been for some time.

> Other people will have other priorities.

I don't believe that any developer will ever be willing to trade quality
code for a snappier build process. Naturally it is a nice feature but there
is absolutely no way it would ever be seriously considered for any
tradeoff.


Rui Maciel

Rui Maciel wrote:
> Erik Trulsson wrote:
>
>> That depends on in what manner you are trying to compete. It is true that
>> it seems unlikely that PCC will be able to generate as good code as GCC
>> anytime in the near future. On the other hand it should not be very
>> difficult to compete with GCC with regards to compile time and memory
>> usage needed by the compiler (areas in which GCC is not very good.)
>
> Properties such as compile time and memory usage are only relevant to the
> compilation process, which is a very tiny part of the whole software
> production process.


I have to disagree here.

Each time you make a change in C you have to rebuild. for many projects,
a change can affect a lot of files. Global changes that need a full
recompilation are done not VERY often, but they are done...

This means that a compiler that slows down the development process by
just 30-60 seconds per build, it is taking between 15-30 minutes per day
to each developer...

Multiply that for a team and you see that a lot of time people are just
waiting for gcc to finish. Of course, this is not visible in small
projects.

> As far as compilers go and what is expected from the
> compiler, those features may be nice to have but they are very far from
> being important. In fact, they are totally irrelevant.
>

Surely not. A fast compiler allows YOU to develop faster. And that is
important. Gcc is not very fast, mind you.

> No one in their right mind prefers a lighter compiler that produces weak or
> buggy code to one which is not so light but produces strong, tight and even
> secure code.
>

You are speaking here as if you had never a gcc bug...

And yes, a compiler can be slow AND buggy, just look at gcc 3.1.xx for
amd64 platform and you will see what a buggy compiler can be. The same
with the 4.0xx and 4.1 series...

A simpler compiler is surely easier to debug you see?

>
>> For people trying to do development on older machines these features can
>> be worth much more than having the generated code run 0.5% faster.
>
> In this day and age anyone can purchase a very capable system with
> multi-core processors for less than 300 euros. It is also possible to buy
> used systems for almost nothing. Frankly, I don't believe that build times
> are an issue anymore or have been for some time.
>

For the company I am working, a full rebuild takes 10 minutes in a super
hyper fast lane dual core amd64 using MSVC. Using gcc it takes like 45
minutes...

>> Other people will have other priorities.
>
> I don't believe that any developer will ever be willing to trade quality
> code for a snappier build process.

Quality of code? Gcc's code quality can be great when there is no bugs
in the optimizer... When they are, as it is sadly very often the case,
we have to use the debug version... And that code is quite bad.

We get then the worst of both worlds: slow AND buggy.

>> Naturally it is a nice feature but there
> is absolutely no way it would ever be seriously considered for any
> tradeoff.
>

Since they have the monopoly under linux, there is nothing
anyone can do about that.

DISCLAIMER:
I am biased against it. I use another compiler.

Rui Maciel <> wrote:
> Erik Trulsson wrote:

> > That depends on in what manner you are trying to compete. It is true that
> > it seems unlikely that PCC will be able to generate as good code as GCC
> > anytime in the near future. ??On the other hand it should not be very
> > difficult to compete with GCC with regards to compile time and memory
> > usage needed by the compiler (areas in which GCC is not very good.)

> Properties such as compile time and memory usage are only relevant to the
> compilation process, which is a very tiny part of the whole software
> production process. As far as compilers go and what is expected from the
> compiler, those features may be nice to have but they are very far from
> being important. In fact, they are totally irrelevant.

> No one in their right mind prefers a lighter compiler that produces weak or
> buggy code to one which is not so light but produces strong, tight and even
> secure code.

Indeed. And in fact, the OpenBSD developers have for years complained that
GCC does not produce strong, tight and secure code. In other words, they
claim that GCC slowly compiles fast, buggy code.

jacob navia wrote, On 18/09/07 14:34:
> Rui Maciel wrote:
>> Erik Trulsson wrote:
>>
>>> That depends on in what manner you are trying to compete. It is true
>>> that
>>> it seems unlikely that PCC will be able to generate as good code as GCC
>>> anytime in the near future. On the other hand it should not be very
>>> difficult to compete with GCC with regards to compile time and memory
>>> usage needed by the compiler (areas in which GCC is not very good.)
>>
>> Properties such as compile time and memory usage are only relevant to the
>> compilation process, which is a very tiny part of the whole software
>> production process.
>
> I have to disagree here.
>
> Each time you make a change in C you have to rebuild. for many projects,
> a change can affect a lot of files. Global changes that need a full
> recompilation are done not VERY often, but they are done...
>
> This means that a compiler that slows down the development process by
> just 30-60 seconds per build, it is taking between 15-30 minutes per day
> to each developer...
>
> Multiply that for a team and you see that a lot of time people are just
> waiting for gcc to finish. Of course, this is not visible in small
> projects.

That is not long. Wait until you work on a project where a build take 8
hours!

>> As far as compilers go and what is expected from the
>> compiler, those features may be nice to have but they are very far from
>> being important. In fact, they are totally irrelevant.
>
> Surely not. A fast compiler allows YOU to develop faster. And that is
> important. Gcc is not very fast, mind you.

Yes, I agree a fast compiler is useful, and gcc is not the fastest around.

>> No one in their right mind prefers a lighter compiler that produces
>> weak or
>> buggy code to one which is not so light but produces strong, tight and
>> even
>> secure code.
>
> You are speaking here as if you had never a gcc bug...
>
> And yes, a compiler can be slow AND buggy, just look at gcc 3.1.xx for
> amd64 platform and you will see what a buggy compiler can be. The same
> with the 4.0xx and 4.1 series...
>
> A simpler compiler is surely easier to debug you see?

Personally I've hit very few bugs in gcc. They do exist but I don't hit
them often enough to worry about.

>>> For people trying to do development on older machines these features can
>>> be worth much more than having the generated code run 0.5% faster.
>>
>> In this day and age anyone can purchase a very capable system with
>> multi-core processors for less than 300 euros. It is also possible to buy
>> used systems for almost nothing. Frankly, I don't believe that build
>> times
>> are an issue anymore or have been for some time.
>
> For the company I am working, a full rebuild takes 10 minutes in a super
> hyper fast lane dual core amd64 using MSVC. Using gcc it takes like 45
> minutes...

A dual core amd64 is *not* super hyper fast. Anyway, make sure you have
make configured to do multiple compilations at once. On Linux it is
often recommended that you set make to compile two files per core at a
time, so on a dual core machine you should be compiling 4 files in parallel.

>>> Other people will have other priorities.
>>
>> I don't believe that any developer will ever be willing to trade quality
>> code for a snappier build process.
>
> Quality of code? Gcc's code quality can be great when there is no bugs
> in the optimizer... When they are, as it is sadly very often the case,
> we have to use the debug version... And that code is quite bad.

At -O2 I've *very* rarely hit problems.

> We get then the worst of both worlds: slow AND buggy.
>
>>> Naturally it is a nice feature but there
>> is absolutely no way it would ever be seriously considered for any
>> tradeoff.
>
> Since they have the monopoly under linux, there is nothing
> anyone can do about that.

No gcc does not have a monopoly under Linux. There is tcc, although that
is still flagged as experimental on Ubuntu, Tendra and of course Intel's
icc.

> DISCLAIMER:
> I am biased against it. I use another compiler.

I use gcc a *lot* under Linux, and historically I have used it a fair
bit under SCO and AIX with some use under Cygwin and MinGW as well and
have not hit the level of bugs you claim for it.
--
Flash Gordon

William Ahern wrote, On 18/09/07 16:06:
> Rui Maciel <> wrote:
>> Erik Trulsson wrote:
>
>>> That depends on in what manner you are trying to compete. It is true that
>>> it seems unlikely that PCC will be able to generate as good code as GCC
>>> anytime in the near future. ??On the other hand it should not be very
>>> difficult to compete with GCC with regards to compile time and memory
>>> usage needed by the compiler (areas in which GCC is not very good.)
>
>> Properties such as compile time and memory usage are only relevant to the
>> compilation process, which is a very tiny part of the whole software
>> production process. As far as compilers go and what is expected from the
>> compiler, those features may be nice to have but they are very far from
>> being important. In fact, they are totally irrelevant.
>
>> No one in their right mind prefers a lighter compiler that produces weak or
>> buggy code to one which is not so light but produces strong, tight and even
>> secure code.
>
> Indeed. And in fact, the OpenBSD developers have for years complained that
> GCC does not produce strong, tight and secure code. In other words, they
> claim that GCC slowly compiles fast, buggy code.

Not secure is not the same thing as buggy. If you want secure code you
want the code to do something safe on buffer overflows, for example, but
as far as the C standard is concerned whatever the code does on a buffer
overflow it is not a bug in the compiler. By strong and tight they could
also mean things which are nothing to do with whether gcc incorrectly
translates code.
--
Flash Gordon

jacob navia wrote:

> Each time you make a change in C you have to rebuild. for many projects,
> a change can affect a lot of files. Global changes that need a full
> recompilation are done not VERY often, but they are done...
>
> This means that a compiler that slows down the development process by
> just 30-60 seconds per build, it is taking between 15-30 minutes per day
> to each developer...
>
> Multiply that for a team and you see that a lot of time people are just
> waiting for gcc to finish. Of course, this is not visible in small
> projects.

That scenario isn't very realistic. From your numbers and, for the sake of
simplicity, assuming that a working day would be 10 hours, in order for a
developer to spend an extra 30 minutes a day on those hypothetical builds
he would have to perform between 30 and 60 complete builds per day, which
would amount to, on average, each and every developer having to run a
complete build every 10 or 20 minutes.

As it is easy to see, that scenario is very unrealistic, not to say
extremely far fetched. In any scenario vaguely resembling that, the
development team would have to deal with more serious problems than the
compiler speed.


> Surely not. A fast compiler allows YOU to develop faster. And that is
> important. Gcc is not very fast, mind you.

In order for the compiler speed to have any measurable impact on the
development speed, you have to compile your code on virtually every small
change you do in the code. If that is the case, you have bigger problems to
deal with than your compiler.


>> No one in their right mind prefers a lighter compiler that produces weak
>> or buggy code to one which is not so light but produces strong, tight and
>> even secure code.
>>
>
> You are speaking here as if you had never a gcc bug...

No one is claiming that GCC is perfect nor that it is the fastest compiler
ever built. In fact, GCC is perfectly irrelevant to this subject.

On the other hand, GCC isn't even remotely the piece of crap which is being
made out to be with this PCC deal. In fact, PCC supporters can only claim
it's "lightness" as the only favourable feature, completely ignoring and
downplaying the fact that PCC is extremely buggy on it's own and doesn't
even try to optimise the code.


> And yes, a compiler can be slow AND buggy, just look at gcc 3.1.xx for
> amd64 platform and you will see what a buggy compiler can be. The same
> with the 4.0xx and 4.1 series...

Once again, GCC is perfectly irrelevant to this subject.
Nonetheless, I've ran a quick check and, according to the GCC project page,
the last release of the 3.1 branch was done in 2002-07-25 and, according to
Wikipedia, the very first processor sporting the AMD 64 architecture was
released in April 2003. In fact, the whole 3.2 branch was released between
the end of the 3.1 branch and the release of the first AMD 64 processor.

So, naturally I have to call bullshit on your statement.


> A simpler compiler is surely easier to debug you see?

Simpler, in the sense that it is virtually void of any feature like
optimisation, support for target platforms and for other languages beyond
C. It won't be of much use but it will be simpler to maintain.


>>> For people trying to do development on older machines these features can
>>> be worth much more than having the generated code run 0.5% faster.
>>
>> In this day and age anyone can purchase a very capable system with
>> multi-core processors for less than 300 euros. It is also possible to buy
>> used systems for almost nothing. Frankly, I don't believe that build
>> times are an issue anymore or have been for some time.
>>
>
> For the company I am working, a full rebuild takes 10 minutes in a super
> hyper fast lane dual core amd64 using MSVC. Using gcc it takes like 45
> minutes...

Once again, GCC is perfectly irrelevant to this subject. Why you keep on
whining about GCC is beyond me. Moreover, no one ever claimed that GCC was
the best compiler around or even the fastest. The claim that was made was
that the "people building on old machines" claim is perfectly irrelevant,
knowing that any system sold in the past 3 or 4 years is more than capable
of doing a decent build job.


>>> Other people will have other priorities.
>>
>> I don't believe that any developer will ever be willing to trade quality
>> code for a snappier build process.
>
> Quality of code? Gcc's code quality can be great when there is no bugs
> in the optimizer... When they are, as it is sadly very often the case,
> we have to use the debug version... And that code is quite bad.
>
> We get then the worst of both worlds: slow AND buggy.


Once again, GCC is perfectly irrelevant to this subject.
Nonetheless, let me get this straight. In your own words GCC does in fact
produce great code but if there happens to be a bug somewhere then GCC is
suddently terrible. Do you honestly believe that right now PCC, which is
void of any basic feature and plagued with bugs, is a better compiler than
GCC's C compiler? Do you believe that taking less time to produce
non-optimised, bug-ridden code is in some way better than the heavily
optimised code that GCC generates or even the fact that it supports dozens
of target platforms and 6 programming languages?


>>> Naturally it is a nice feature but there
>> is absolutely no way it would ever be seriously considered for any
>> tradeoff.
>>
>
> Since they have the monopoly under linux, there is nothing
> anyone can do about that.

Monopoly? What the hell are you talking about? No one forces anyone or any
linux distro to adopt GCC nor anyone bars anyone from installing and using
some other compiler on a linux distro. Some companies even sell compilers
for linux. Heck, some linux distros even compile their binaries with other
compilers such as Intel's. What on earth are you smoking?


Rui Maciel