Contributed by ray on from the gcc-annihilation dept.
Anders Magnusson <ragge@> has teamed up with BSD Fund to raise funds to bring pcc to a usable 1.0 status and map out a solid, all-BSD toolchain. Support for an alternative to GCC in OpenBSD has been steadily growing and this effort aims to turn that concern into code.
Please help spread the word to sympathetic employers and philanthropists, and US donors qualify for a tax deduction.
(Comments are closed)
By Anonymous Coward (87.194.34.157) on
By Dean (63.227.127.121) on
Comments
By Martin Toft (130.225.243.84) on
Me too! :-D
Comments
By Jacek Masiulaniec (86.138.154.228) on
>
> Me too! :-D
Another $50 is on the way.
Comments
By Shane J Pearson (59.167.252.29) on
> >
> > Me too! :-D
>
> Another $50 is on the way.
And I.
Comments
By Anonymous Coward (79.129.240.205) on
> > >
> > > Me too! :-D
> >
> > Another $50 is on the way.
>
> And I.
>
Another $50 from me too
Comments
By Colin D. (cdidier) on http://cybione.org/
> > > >
> > > > Me too! :-D
> > >
> > > Another $50 is on the way.
> >
> > And I.
> >
> Another $50 from me too
>
And 40 euros from me.
By Ryan Flannery (24.172.134.210) ryan.flannery@gmail.com on http://www.ryanflannery.net
This will be awesome!
By Anonymous Coward (213.185.19.190) on
Comments
By Anonymous Coward (85.19.213.88) on
$25 from me, too. I know, it's not much, but it's at least /something/.
Comments
By Anonymous Coward (86.121.135.211) on
By Anonymous Coward (84.58.224.166) on
By Anonymous Coward (66.42.181.241) on
~10000, ~100,000, ~1,000,000?
Comments
By diw (diw) on
> ~10000, ~100,000, ~1,000,000?
One of the links provided up top (usable 1.0 status) goes here:
http://www.bsdfund.org/projects/pcc/
Have a read. :]
Quote:
"Donations needed to complete this work: $12,000".
Best wishes.
By Anonymous Coward (83.171.149.31) on
Just a quick question: who will get this money? Will it be given directly to ragge@?
Just asking as I didn't find any information about this (and I find this quite important to know).
Comments
By Ragge (79.138.4.2) on
> Will it be given directly to ragge@?
> Just asking as I didn't find any information about this (and I find this quite important to know).
The fund will get the money and then pay it to me after I completed each of the milestones on the web pages. I've been discussing pcc with the fund for some weeks and I think they have made a great work so far!
Comments
By Anonymous Coward (83.171.149.31) on
> > Will it be given directly to ragge@?
> > Just asking as I didn't find any information about this (and I find this quite important to know).
>
> The fund will get the money and then pay it to me after I completed each of the milestones on the web pages. I've been discussing pcc with the fund for some weeks and I think they have made a great work so far!
>
Thank you for your answer!
By Anonymous Coward (79.129.240.205) on
> > Will it be given directly to ragge@?
> > Just asking as I didn't find any information about this (and I find this quite important to know).
>
> The fund will get the money and then pay it to me after I completed each of the milestones on the web pages. I've been discussing pcc with the fund for some weeks and I think they have made a great work so far!
>
Good luck buddy, you make us proud
By Jan J (130.237.95.28) on
> completed each of the milestones on the web pages. I've been
> discussing pcc with the fund for some weeks and I think they
> have made a great work so far!
So should I send my Swedish Kronor to you directly or through the
foundation (and loose some on exchange rates)?
Comments
By ragge (ragge) on
> > completed each of the milestones on the web pages. I've been
> > discussing pcc with the fund for some weeks and I think they
> > have made a great work so far!
>
> So should I send my Swedish Kronor to you directly or through the
> foundation (and loose some on exchange rates)?
>
:-) Please go through the fund. I will take unpaid vacation from my daytime job to do pcc development, therefore I need to get all papers correct for the swedish tax authority, which I have managed to fix with the fund.
By Andrés Delfino (201.212.54.77) adelfino@gmail.com on
By Bob Brinks (83.145.244.66) on
I'm under the impression that PCC will be a lot more faster than GCC is right now? Right? What about the optimization of the resulting code essentially? Does it compete there with GCC, or is it even better than GCC? How about cross platform support? Will the thing compile Motorola 88k code, or perhaps MIPS code, and so forth, and in that case, will it be well optimized, for all architectures, or will you focus on some primary arch in the first place? Will there be a Linux port? :) No seriously, I would love to see something else than GCC on Linux as well, as probably a lot of us are forced to deal with Linux, whether we like it or not. Will code compiled with PCC link with GCC code, and wise versa, or do we have to install upgrades or deal with a flag day thingie?
Has NetBSD or FreeBSD, or DragonFlyBSD indicated that they want to have PCC in their system as the primary compiler of C code? Or is it just OpenBSD? And, are there any parts of /usr/src that are not written in C, but rather something blasphemous like C++?
Please, do not flame me, I'm honestly just interested, and I think this is a kick ass thing to happen. GCC has probably been out there too long without competition essentially, and it's a good thing, amongst other good things, that somebody will kick them in the ass and give them a good reason to improve things. :)
Comments
By ragge (ragge) on
>
I think that most of the info you want is on the pcc website, but I can try to give a summary here.
> I'm under the impression that PCC will be a lot more faster than GCC is right now? Right?
Right. If you turn off the internal sanity checking in the compiler it is about 15 times faster than gcc. With sanity checks on it's only about 5 times faster...
> What about the optimization of the resulting code essentially? Does it compete there with GCC, or is it even better than GCC?
The resulting code as it is right now is at an average 10% slower, but the only optimization currently added is the register allocator. There are a bunch of other optimizing stuff that should be added.
> How about cross platform support? Will the thing compile Motorola 88k code, or perhaps MIPS code, and so forth, and in that case, will it be well optimized, for all architectures, or will you focus on some primary arch in the first place?
There are currently ~10 targets for which it exists some support, but the most tested target is the i386. It is quite fast to write a new target, a few days and you have the compiler running. The optimizer is mostly target-independent, so the resulting assembler will be optimized independent of target.
> Will there be a Linux port? :) No seriously, I would love to see something else than GCC on Linux as well, as probably a lot of us are forced to deal with Linux, whether we like it or not. Will code compiled with PCC link with GCC code, and wise versa, or do we have to install upgrades or deal with a flag day thingie?
Yes, it's just a compiler and it works under Linux also. I even think there was someone at Redhat that made rpm's for it. For plain C object files the ABI is usually ELF and therefore specified, so cross-linking is not a problem.
>
> Has NetBSD or FreeBSD, or DragonFlyBSD indicated that they want to have PCC in their system as the primary compiler of C code? Or is it just OpenBSD? And, are there any parts of /usr/src that are not written in C, but rather something blasphemous like C++?
>
NetBSD have pcc in its base system as well as in pkgsrc, and I think some Dragonflyers have been hacking on it.
> Please, do not flame me, I'm honestly just interested, and I think this is a kick ass thing to happen. GCC has probably been out there too long without competition essentially, and it's a good thing, amongst other good things, that somebody will kick them in the ass and give them a good reason to improve things. :)
Hope you got the answers you wanted...
Comments
By Anonymous Coward (80.37.248.67) on
Under which conditions? Which level of optimization are you using for the gcc benchmarks? Which version? 90% of gcc's performance with a register allocator alone is quite a claim.
Comments
By ragge (ragge) on
> > The resulting code as it is right now is at an average 10% slower, but the only optimization currently added is the register allocator. There are a bunch of other optimizing stuff that should be added.
> Under which conditions? Which level of optimization are you using for the gcc benchmarks? Which version? 90% of gcc's performance with a register allocator alone is quite a claim.
Yes, it is. I haven't tested it since I wrote the register allocator some years ago, so it may have been against 2.95. I used bytebench. Hm, a rerun on some of the passes shows that the difference is not much more against gcc 3.3.5 with -O2:
The cases where pcc is significantly slower is missing optimizations like strength reduction etc.By Chris (LizardKing) hatemail@chriswareham.demon.co.uk on www.chriswareham.demon.co.uk
Ragge is a cool guy - he is (or at least was) maintainer of the NetBSD VAX port, and I hope he gets the funding he needs to increase the pace of pcc development. An ARM backend would be a great future addition, and lacking the ability to do this myself, it's certainly something I'd donate further money for.
One thing I've been wondering about though, is that there appears to be one significant chunk of C++ code in the NetBSD and OpenBSD codebases. This is groff, and as pcc is aiming to be solely a C compiler at the moment maybe it's time to port groff from C++ to C?
Comments
By tedu (udet) on
> One thing I've been wondering about though, is that there appears to be one significant chunk of C++ code in the NetBSD and OpenBSD codebases. This is groff, and as pcc is aiming to be solely a C compiler at the moment maybe it's time to port groff from C++ to C?
It wouldn't be the end of the world to retain g++ in the system, but a complete non-GNU rewrite would make more sense than trying to un++ groff.
Comments
By Anonymous Coward (71.162.16.142) on
Do we need groff for anything other than formatting man pages? Could we discard groff and just replace it with a nice clean implementation of nroff?
By Anonymous Coward (92.249.232.176) on
If I remember well, there is another free troff implementation, the one is in Minix. Is it possible to use that version in *BSD?
Comments
By Anonymous Coward (99.231.56.170) on
It's known as cawf. It provides a subset of nroff functionality.
It's in the NetBSD ports tree and is available here: http://www.tux.org/pub/sites/vic.cc.purdue.edu/
Comments
By Anonymous Coward (71.162.16.142) on
>
> It's known as cawf. It provides a subset of nroff functionality.
Or, he might be talking about NR
The same thread also discusses a public domain nroff clone named proff.And just for the sake of completeness (so that this thread can die), I should mention that there's a FreeDOS clone of nroff called NRO
But seriously, wouldn't it just be easier to implement OUR OWN nroff clone, rather than trying to port somebody else's musty old code?
By Predrag Punosevac (71.50.109.51) on
original Troff is now open source. It is a part of Heirloom Project
http://heirloom.sourceforge.net/doctools.html
It is written in pure C so that would solve the problem of any significant components in the base system which require C++. However, I think, I have a very bad news about its license. It appears to be CDDL license. Does anybody has enough influence over Gunnar Ritter or who ever has a control over it to release it also under BSD license?
On the final note, Groff in the base of OpenBSD is 1.15 while the current
Groff release is 1.19 so eventually something will have to be done about
it. If the Heirloom Troff had BSD license natural thing to do would be
to replace Groff with the real Troff.
There must be some symbolism in talking about PCC on the eve of the release of OpenBSD 4.4. As you probably know PCC was removed from 4.4 BSD Light and OpenBSD 4.4 might be the last release to contain GCC.
I congratulate the developer of the PCC for his hard work and I can not wait for the moment when PCC will be back home:-)
It looks like puffy might slim down to less than 300Mb for the next release. That would be so COOL!!!
Comments
By tedu (udet) on
Not by a long shot.
Comments
By Igor Sobrado (sobrado) on
>
> Not by a long shot.
Well, at least we have a chance to get a superb C compiler in the base system in some years--it is more than we had two years ago. To be honest, working on the compiler written by Stephen C. Johnson seems the best choice to me. It is not just a licensing issue, the goals of pcc and the history behind this project are the right ones. If we get pcc in base in two or three years... excellent! (wow, I do not expect it become available on the base system so fast). If pcc is available in base in five or six years, it will certainly be fine too.
Now it seems that pcc is not only what Anders Magnusson announced a year ago (a well written, simple and fast C compiler targeted to support multiple architectures) but it is also a serious competitor to gcc. I just hope they will continue their fine work with the FORTRAN 77 compiler (just to get it working right, the main target for the developers must be the C compiler). Having a fast and updated compiler (pcc supports C99!) in the base system will be really great.
By Anonymous Coward (71.162.16.142) on
> Troff has always been a part of the Unix base so I think it should stay there.
Not true. According to the O'Reilly Unix In A Nutshell, "nroff and troff are not part of standard SVR4 but are included in the compatibility packages... Some Unix vendors include a vendor-specific version of nroff/troff. Others don't include them at all."
Comments
By Igor Sobrado (2001:b18:401c:200:212:f0ff:fe24:cfe3) on
> > Troff has always been a part of the Unix base so I think it should stay there.
>
>
> Not true. According to the O'Reilly Unix In A Nutshell, "nroff and troff are not part of standard SVR4 but are included in the compatibility packages... Some Unix vendors include a vendor-specific version of nroff/troff. Others don't include them at all."
You are probably thinking on the Documenter's WorkBench. ;-)
roff has been a part of BSD systems for a lot of years and, before that, Unix was targeted to document typesetting... so some flavor of [nt]roff will be required. On the other hand, the mandoc-based manual pages will not look so nicely without roff. :-)
The Heirloom project is something that should certainly be considered.
I would like to see groff replaced with a real roff written in a sane programming language. Right now things are not worse than thirty years ago. Understanding a few macro packages (like -mdoc) and being able to provide output for character terminals, PostScript devices, and (perhaps) html[*] will be enough.
[*] I am certainly not a fan of html, but it may be useful to provide on-line copies of the manual pages.
By Igor Sobrado (156.35.192.2) on
> It is written in pure C so that would solve the problem of any significant components in the base system which require C++. However, I think, I have a very bad news about its license. It appears to be CDDL license. Does anybody has enough influence over Gunnar Ritter or who ever has a control over it to release it also under BSD license?
I am not a lawyer, so do not trust on me a lot... I suppose that, even if Mr. Ritter does not want to release the code under dual licensing terms, there is a chance to ask Caldera for a copy of the original source code. pcc comes from Caldera too, and it has more reasonable licensing terms.
Comments
By Anonymous Coward (71.162.16.142) on
Read
The troff code in the Heirloom project comes from OpenSolaris, which is why it has a CDDL license. Sun is the only organization which could legally relicense it.Comments
By Igor Sobrado (156.35.192.2) on
I see, then it seems that the license will be a concern. Thanks for the reference.
Comments
By mirabilos (2a01:198:25d:0:20a:e4ff:fe32:17b2) tg@mirbsd.org on http://mirbsd.de/mksh
> the reference.
People say that *roff from Plan 9 might be interesting;
I haven't yet looked into it because it has too many
dependencies for easy integration at first.
However, I *did* talk with Theo at FOSDEM about two other
*roff implementations. One is based upon the old nroff/troff
from 4.4BSD-Alpha, under the same Caldera licence as pcc;
MirBSD currently has it in the base system, but the code is
ugly, still produces (very) slightly broken output under
some (rare) circumstances (more so on sparc than on i386),
and requires compiling with -O1 (hmm, maybe I should try
and use pcc in that code instead...). It also contains only
nroff and a few support utilities; while I could have por-
ted pic and troff, the latter only supports that ancient
typesetter nobody has any more, and its pic is specific to
that as well.
For these interested, check out src/usr.bin/oldroff from
anoncvs@anoncvs.mirbsd.org:/cvs - and, possibly, the macros
from src/share/tmac which are based upon these delivered
with 4.4BSD-Alpha, enhanced by what comes with OpenBSD, and
fixed for use with oldroff. Together with src/usr.bin/soelim
(stock from OpenBSD) I managed to use it on Interix (Micro-
soft Services for Unix) quite well, which has no native *roff.
Then I managed to obtain a tape archive of a direct de-
scendant of ditroff, which _does_ PostScript optionally.
It was enhanced by some UK academics who cannot legally
claim copyright on their changes, and all the mtimes are
from a time before the USA signed the Berne convention,
and there are no explicit copyright notices on it. Theo
however said that, while it would be in the Public Domain
in the USA, we (he as Canadian and I as German citizen)
cannot legally use it without an explicit licence, as our
countries signed the Berne convention much earlier. Brian
Kernighan (the obvious author) is currently unable to pro-
vide a licence for it, because he had written it under em-
ployment, and nobody seems to be responsible for said code
any longer. (They did suggest some alternatives, and for
a fact I know that even SCO uses GNU groff - yuck C++ -
and tried to be helpful, but...)
Comments
By Igor Sobrado (156.35.192.2) on
> > the reference.
>
> However, I *did* talk with Theo at FOSDEM about two other
> *roff implementations. One is based upon the old nroff/troff
> from 4.4BSD-Alpha, under the same Caldera licence as pcc;
> MirBSD currently has it in the base system, but the code is
> ugly, still produces (very) slightly broken output under
> some (rare) circumstances (more so on sparc than on i386),
> and requires compiling with -O1 (hmm, maybe I should try
> and use pcc in that code instead...). It also contains only
> nroff and a few support utilities; while I could have por-
> ted pic and troff, the latter only supports that ancient
> typesetter nobody has any more, and its pic is specific to
> that as well.
It would be very nice to look at it. Indeed, it seems that there is a lot of work to be done, but it is a good goal too.
> For these interested, check out src/usr.bin/oldroff from
> anoncvs@anoncvs.mirbsd.org:/cvs - and, possibly, the macros
> from src/share/tmac which are based upon these delivered
> with 4.4BSD-Alpha, enhanced by what comes with OpenBSD, and
> fixed for use with oldroff. Together with src/usr.bin/soelim
> (stock from OpenBSD) I managed to use it on Interix (Micro-
> soft Services for Unix) quite well, which has no native *roff.
I have checked it out right now... 1.6 MB... its size is comparable to the one of pcc. I am really interested on trying it.
> Then I managed to obtain a tape archive of a direct de-
> scendant of ditroff, which _does_ PostScript optionally.
> It was enhanced by some UK academics who cannot legally
> claim copyright on their changes, and all the mtimes are
> from a time before the USA signed the Berne convention,
> and there are no explicit copyright notices on it. Theo
> however said that, while it would be in the Public Domain
> in the USA, we (he as Canadian and I as German citizen)
> cannot legally use it without an explicit licence, as our
> countries signed the Berne convention much earlier. Brian
> Kernighan (the obvious author) is currently unable to pro-
> vide a licence for it, because he had written it under em-
> ployment, and nobody seems to be responsible for said code
> any longer. (They did suggest some alternatives, and for
> a fact I know that even SCO uses GNU groff - yuck C++ -
> and tried to be helpful, but...)
It is sad losing that nice package just because it has no licensing terms and was written before Berne convention. Perhaps someone at Bell Labs would be able to help (Bell Labs is the owner of that source, right?). It seems that this software will just be lost if no one is able to license it under some reasonable terms, and this small code may greatly help us.
Perhaps this idea sounds crazy (remember, I am NOT a lawyer), and it really sounds very crazy to me but need to ask... if this software is in the public domain in the USA, may a US citizen write a derivative work of it and release it to the world? I suppose that this path has been considered and rejected by some good reason, but I would like to ask.
Cheers,
Igor.
By minusf (92.101.14.46) on
close it is to be usable (based on the presentation
at the new york user group meeting one gets the
impression it's basically ready for use..) is
propolice.
that's right. going with pcc would mean losing propolice,
wouldn't it?
Comments
By ragge (ragge) on
> close it is to be usable (based on the presentation
> at the new york user group meeting one gets the
> impression it's basically ready for use..) is
>
> propolice.
>
> that's right. going with pcc would mean losing propolice,
> wouldn't it?
It can compile both the NetBSD and OpenBSD source trees with some
patches to avoid the gcc specifics that are not supported.
Propolice (or SSP as it is called) is implemented and works in
some sense, but I think it may need a little bit more work.
(I didn't write it myself).
By Dennis Decker Jensen (85.83.52.4) dennis@cyg.dk on
--Dennis
By Andrés Delfino (201.212.54.77) adelfino@gmail.com on
By Anonymous Coward (85.19.213.88) on
So from now on, every month when I get my paycheck I will try to donate $25 to OpenBSD (or any other OpenBSD-related project that needs funding). Is anyone else doing this? If not, why not? If you do, how much do you donate?
By Michael Dexter (87.246.136.51) on
Donating countries include, in no particular order: the US, the United Kingdom, the Netherlands, Canada, Germany, France, Finland, Sweden, Denmark, Spain, Japan, Brazil, Chile, Romania, South Africa, Switzerland and Estonia. Congratulations on maintaining one of the tightest communities on the Internet.
By Brynet (Brynet) on
By Michael Dexter (87.246.136.51) on