PCC reached version 1.0

[Mr-Biscuit]

http://www.h-online.com/open/news/it...0-1220995.html

A little late but still good news.

[TerryP]

Any recent updates on the OpenBSD+PCC combo?

[BSDfan666]

Not really, no, Anders Magnusson had commit access to OpenBSD's CVS repository once.. but he hasn't committed since 2009.

There hasn't been any commits to pcc in OpenBSD's tree lately, It seems as if developer interest has died down a bit.. mostly due to PCC only supporting i386/amd64 primarily at the moment.

OpenBSD will probably continue using GCC until maintaining their forks of gcc2/3/4 is no longer feasible.. they can't port bugfixes from upstream GCC due to the license change to GPLv3, fixes have to be done independently or taken from other forks.

[ocicat]

Originally Posted by BSDfan666

OpenBSD will probably continue using GCC until maintaining their forks of gcc2/3/4 is no longer feasible..

The OpenBSD project will continue to use gcc(1) until there is a viable alternative which supports all platforms in which the project supports.

[TerryP]

I really wonder what is worse nightmare, having to implement the necessary ports of PCC, or maintain the relevant pieces of GCC :-/.

[backrow]

There is some C++ in Xenocara, notably Mesa. So either it will have to be rewritten or disabled, or gcc will be kept around to deal with it.

Architecture support is improving in PCC (such as MIPS, iirc) but currently not up to the OpenBSD standard either. PCC is easy to extend to new architectures—the i386 port took only a few days—but that requires someone willing to work on and maintain the compiler for that architecture…

[Oko]

Originally Posted by backrow

There is some C++ in Xenocara, notably Mesa. So either it will have to be rewritten or disabled, or gcc will be kept around to deal with it.

PCC is intended to be a system compiler. One could argue that Mesa and Xenocara are not part of the core system but provided as a convenience to users. Compiling Xenocara is usually never needed. If you need to compile Xenorara GCC could be pulled as a dependence just like it is going to be pulled for many ports. There are even ports like MPlayer that explicitly require GCC and can not be compiled with any other open or close source compilers.

[BSDfan666]

Xenocara is part of the base system, as is Mesa.

Building the userland, including X, has never involved the ports tree.. and while regular users are not encouraged to build X themselves, that doesn't mean it isn't a critical component of the base system that gets built by the developers.

These days it's almost discouraged NOT to install the X sets.

[Oko]

Originally Posted by BSDfan666

Xenocara is part of the base system, as is Mesa.

Building the userland, including X, has never involved the ports tree.. and while regular users are not encouraged to build X themselves, that doesn't mean it isn't a critical component of the base system that gets built by the developers.

These days it's almost discouraged NOT to install the X sets.

Then I can easily see the situation in the future in which there would be choice for OpenBSD either to completely fork X and kill C++ Mesa (and possibly some other things which might in future be written in C++) or to add support for C++ to PCC which is probably even more difficult.

[jggimi]

Point of clarification -- the encouragement is for xbase*.tgz only, which may be needed for select ports.

[BSDfan666]

Originally Posted by jggimi

Point of clarification -- the encouragement is for xbase*.tgz only, which may be needed for select ports.

But we're talking about building, in which case all of Xenocara is compiled and then the sets are built.

[jggimi]

But you were talking about "encourged to install" -- but no biggie, sorry for the confusion.

[TerryP]

For C++, it may be a moot point for PCC, from the referenced article ->

Future plans include a nearly-complete F77 compiler and a C++ front end that is mid-way through development.

. Which would likely make it even more effort for OpenBSDs non x86-related platforms.

Last I can remember, OpenBSD did have support for C, C++, and Fortran but it's been a while since I've cuddled up to OpenBSDs base system.

[rocket357]

Originally Posted by TerryP

For C++, it may be a moot point for PCC, from the referenced article -> . Which would likely make it even more effort for OpenBSDs non x86-related platforms.

As long as there's a good clean separation between parsers and code generators (yes, that's an extreme oversimplification), a C++ frontend shouldn't really impact the architecture-specific code generators. Perhaps I've oversimplified to the point of overlooking issues, but my understanding is that keeping the frontend and backend as separate as possible (something that gcc does a piss-poor job of) alleviates these issues.

[BSDfan666]

Originally Posted by jggimi

But you were talking about "encourged to install" -- but no biggie, sorry for the confusion.

But I said almost!

[ocicat]

Originally Posted by rocket357

Perhaps I've oversimplified to the point of overlooking issues, but my understanding is that keeping the frontend and backend as separate as possible (something that gcc does a piss-poor job of) alleviates these issues.

Actually this is correct, & I can vouch that one commercial i386 compiler did just this. Front-end problems were completely divorced from code generation issues.

[rocket357]

Originally Posted by ocicat

Actually this is correct, & I can vouch that one commercial i386 compiler did just this. Front-end problems were completely divorced from code generation issues.

I own and read the dragon book...but I've never written a compiler, so my information is all theory and no practice... it's good to know that the theory matches reality (if even only sometimes) heh

I've actually considered digging into the PCC code and seeing what I can do to help it along...but I rarely have time for side projects =\

[ocicat]

Originally Posted by rocket357

...it's good to know that the theory matches reality (if even only sometimes) heh

Everything is fair in love & war & compiler implementation, but separation between front-end syntax checking, intermediate parse tree creation, & back-end code generation can be an easy discipline to maintain. With as many processors that gcc supports, one would think that separating out the code generation code would be a given, but I haven't looked at it, so I can only conjecture.

[Oko]

Originally Posted by ocicat

With as many processors that gcc supports, one would think that separating out the code generation code would be a given

GCC doesn't separate back and front ends by design!!! RMS was afraid that such a properly designed compiler would be more interested for industry to "steal" . You can find about some of similar "bright" ideas and the reasons for their implementation from various e-mail list all over the Internet.

[rocket357]

Originally Posted by Oko

You can find about some of similar "bright" ideas and the reasons for their implementation from various e-mail list all over the Internet.

I looked, because I remember reading that RMS had intentionally "misdesigned" gcc like you described, but for the life of me I couldn't find the mailing list thread I remember reading that in.