Subject: Re: GCC to retire VAX support!?
To: Anders Magnusson <ragge@ludd.luth.se>
From: Lord Isildur <mrfusion@uranium.vaxpower.org>
List: port-vax
Date: 06/19/2002 09:45:03
we've had this thread before.. one of the things i found in comparing 
them was that while the gcc optimizer was better, it wasnt 100% better, 
and also, the stuff in the gnu C linrary ran a lot slower than that stuff 
in the old C library. printf() for example, despite the superior 
optimizer in gcc, took way longer when using the gnu tools and libs, than 
pcc with the old BSD C library did, in a program that made heavy use of 
it. both were compiled statically to eliminate the small speed penalty 
for using the shared libs, too. the bloat in the GNU stuff in general is 
the problem. sure, the gnu optimizer generates faster code. then it makes 
up for it with interest when it comes to using the mega-bloated gnu code 
in libc and pals.. 
now, as for slow code vs clow compile, when im developing, i find i do 
much less running of the code than i do wquick test, kill it, edit, 
recompile. waiting for long compiles is extremely frusrating, and i dont 
care about optimization while im just trying to get the right behavior. 
it is very distressing that the dec/mips C compiler runs faster on my 
decstation 5000 than gcc does on my alpha. (gcc on the decstation is like 
gcc on a vax, its so slowi seldom even bother, and on a pmax, one does 
not have the issue of the vendor compiler geenrating slow code)

i still espouse the suggestion of making a gcc configuration that tries 
to minimize the bloat, and im willign to help on that. 



On Wed, 19 Jun 2002, Anders Magnusson wrote:

> > Anders Magnusson wrote:
> > > 
> > > >
> > > > That would be wasted effort.  Are you going to add C++ to PCC?  Are you
> > > > going to add Fortran to PCC?  Are you going to make PCC emit debug info
> > > > that modern debuggers like to use?
> > > >
> > > Fortran has been a part of PCC for at least 20 years. But no, there
> > > are no reason to spend any time on that compiler unless someone really
> > > really feel like a masochist. I have spent some time inside it, and even
> > > if it is small and slim it generates quite bad code. The only positive
> > > thing with it is that it is very simple to add new targets, a useable
> > > machine description for something can be written in almost a few hours.
> > > 
> > > -- Ragge
> > 
> > It also doesn't take several cpu-days to build a kernel.
> > 
> Well, if your goal is to compile fast, not to run fast binaries, so OK.
> An average PCC compiled binary runs about half the speed compared to 
> a GCC ompiled one.
> 
> -- Ragge
>