Is it time that we start seriously thinking about using a different compiler?
ANSI C extensions for pcc2 would be my recommendation, assuming i had the 
time to do it.. i wouldn tbe able to touch such a project for numerous 
months though. The only impediment to using pcc/pcc2 generally is that 
it's a K&R compiler, and so much code written since will just barf. 
Otherwise it's a fine compiler, fast, simple, and generates very good code!
(refer to the little 'dc' shootout ragge and i did between pcc2, ultrix's
cc, and gcc a while back)
It was in the net/2 distro, and thus should be unencumbered, and there wont
be problems of licenses then for it. 

isildur

On Mon, 22 Jan 2001, Chuck McManis wrote:

> At 02:28 PM 1/22/2001 -0500, you wrote:
> >Over the weekend I did some simple compiler tests on the NetBSDs
> >and other OS's I have up on my MicroVAX II critters.
> 
> Thank you Bob for investing this time, solid numbers are always better than 
> "it feels slower." !
> 
> >OS                           Gkermit compile time (m:s)
> >--------------------------   --------------------------
> >4.3BSD-Tahoe PCC             3:01
> >Ultrix 4.2 VAX-C             2.50
> >NetBSD-1.2 gcc 2.72          5:05
> >NetBSD-1.3 gcc 2.72.1        6:07
> >NetBSD-1.4.3 gcc 2.91        7:08
> >NetBSD-1.5 gcc 2.91          7:40
> >--------------------------   --------------------------
> 
> Try compiling it with pcc on the NetBSD 1.5 system, using 4.3 
> compatibility. I suspect you will get about 3:20 for that one.
> 
> 
>  > Clearly, the effects of bloat are beginning to overburden
>  > the lowly slower-than-1-VUP box. ... Ultrix C is well optimized
>  > for running on the VAX. gcc 2.91 sucks on slow machines.
> 
> This is my current candidate for attack. One of the issues with EGCS and 
> the GCC folks getting together is that the GCC folks brought the "PC 
> Mindset" which includes the feeling that memory is free. Anyone who has 
> written a compiler will tell you that you can burn memory to get better 
> optimizations quickly. This is what GCC seems to do most often. The impact 
> is a bigger memory footprint for the GCC image as it runs, which causes 
> swapping which causes slowness. I now run with an MFS /tmp on my build 
> machine and with TMPDIR set to /tmp to speed things up (it does by about 
> 30%) But that only works on machines where you can burn memory (and 
> explains why I want to make my 4000/90 128M :-)
> 
> The last time I complained about this to the EGCS folks the answer was "but 
> PeeCees are so cheap, just buy one and cross compile!" Not my answer of choice.
> 
> --Chuck
> 
>