A Portable C Compiler

[jacob navia]

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=article&sid=20070915195203&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.

[user923005]

Re: A Portable C Compiler

On Sep 17, 2:53 pm, jacob navia <ja...@jacob.re mcomp.frwrote:

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=article&sid=20070915195203&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

[Erik Trulsson]

Re: A Portable C Compiler

user923005 <dcorbit@connx. comwrote:

On Sep 17, 2:53 pm, jacob navia <ja...@jacob.re mcomp.frwrote:

>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
ertr1013@studen t.uu.se

[Rui Maciel]

Re: A Portable C Compiler

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

[jacob navia]

Re: A Portable C 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.

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.

[William Ahern]

Re: A Portable C Compiler

Rui Maciel <rui.maciel@gma il.comwrote:

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.

[Flash Gordon]

Re: A Portable C Compiler

William Ahern wrote, On 18/09/07 16:06:

Rui Maciel <rui.maciel@gma il.comwrote:

>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

[Flash Gordon]

Re: A Portable C Compiler

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

[Rui Maciel]

Re: A Portable C Compiler

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

[William Ahern]

Re: A Portable C Compiler

Rui Maciel <rui.maciel@gma il.comwrote:
<snip>

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.

And yet, it is being seriously considered by OpenBSD and NetBSD. The OpenBSD
folks have specifically stated that they would prefer a faster build to
faster code.

Your overly broad and loaded "quality" argument serves only to muddy the
waters. GCC's output isn't shinier than any other output.

[Al Balmer]

Re: A Portable C Compiler

On Tue, 18 Sep 2007 13:34:02 +0100, Rui Maciel <rui.maciel@gma il.com>
wrote:

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

So, either the compiler in question does not fit that description, or
the BSD programmers are not in their right mind. Or both?

--
Al Balmer
Sun City, AZ

[Rui Maciel]

Re: A Portable C Compiler

Al Balmer wrote:

So, either the compiler in question does not fit that description, or
the BSD programmers are not in their right mind. Or both?

You have to ask them why they decided to invest their time in that
endeavour. Personally I hope PCC matures and becomes an excellent compiler.
Everyone benefits if there is another FLOS compiler available. I would be
very happy if it could also support C++ and Fortran and could also offer
better support for the standards.

Nonetheless, the only reasons that so far have been given to justify it's
adoption was PCC's reduced compilation times and it's license. It has been
speculated that the later has been the main reason. If that's the case then
I have to say that they don't seem to be in their right minds.


Rui Maciel

[Rob Kendrick]

Re: A Portable C Compiler

On Tue, 18 Sep 2007 22:33:15 +0200, jacob navia wrote:

This is normal for me.
>
A build after 10 minutes is quite normal when I am developing. Maybe
more. I made a typing mistake, and discover that at link time...
or, I misspelled a variable, or called the wrong function, then you
correct and build again. A normal thing...

Just a minute - surely you only have to do this if you typo in a header?
Or is your build system screwed? Or perhaps you keep code in headers?

(Otherwise only the file you changed generally needs to be rebuilt,
depending on your dependency tree.)

B.

[jacob navia]

Re: A Portable C Compiler

Rob Kendrick wrote:

On Tue, 18 Sep 2007 22:33:15 +0200, jacob navia wrote:
>

>This is normal for me.
>>
>A build after 10 minutes is quite normal when I am developing. Maybe
>more. I made a typing mistake, and discover that at link time...
>or, I misspelled a variable, or called the wrong function, then you
>correct and build again. A normal thing...

>
Just a minute - surely you only have to do this if you typo in a header?
Or is your build system screwed? Or perhaps you keep code in headers?
>
(Otherwise only the file you changed generally needs to be rebuilt,
depending on your dependency tree.)
>
B.

Of course, only one file is rebuilt. But there is always the link step,
what is not fast really, specially with BIG projects.

[Rob Kendrick]

Re: A Portable C Compiler

On Tue, 18 Sep 2007 23:31:30 +0200, jacob navia wrote:

Of course, only one file is rebuilt. But there is always the link step,
what is not fast really, specially with BIG projects.

Woah, 10 minutes of *linking* ? I think it's time you investigate making
your build system suck less.

B.