Subject: Re: Observations on NetBSD VAX on old machines.....
To: Thomas Dzubin <dzubint@vcn.bc.ca>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: port-vax
Date: 03/17/2003 07:33:09
On Mon, Mar 17, 2003 at 06:31:23AM -0800, Thomas Dzubin wrote:

 > I'm in complete agreement.  I'm a "minimalist" in personality and
 > something about GCC and its kitchen-sink attitude has always
 > bothered me.   It just "feels wrong" to need a great big honkin'
 > compiler app & libraries to compile the kernel.

You don't need "great big honkin'" libraries to build the kernel.  The
kernel does not link against libgcc.

libgcc isn't that big, in any case.  On my Alpha system, the entire
library is like 190K.  Most of the time, libgcc is used to provide
primitives where the compiler can't expand into machine code directly,
e.g. __muldi3() (multiple 2 double-integers [64-bit values]) on certain
machines.

 > (yeah, I've got two copies of "Lions' Commentary on UNIX 6th Edition"
 > on my bookshelf...so my warped idea of the "ideal" kernel source code
 > is minimal C with no inline assembly, and a smattering of hardware
 > -dependant assembly files)

Heh, it certainly was "minimal".  6th Edition would not be compilable
with any modern C compiler.  Hell, I don't think it'd be compilable with
most *old* C compilers...

 > I would have no problem with one compiler for the just the kernel
 > and another compiler (GCC) for apps.

What would that gain us, besides pain?  Note this is what Linux often
has to do, but for a different reason -- their kernel code uses GCC
extensions heavily (MUCH more heavily than ours), and they often depend
on the implementation of those extensions in specific versions of GCC.

 > I think I'm probably sticking with the 1.5.2 NetBSD VAX code forever.

That's certainly your perogative.  But I think most of the problems that
people are really experiencing have to do with *tuning*, not fundamental
implementation problems.

Simon Burge a while back posted an interesting mail about this 8MB RAM
PC532 being dog slow under -current, but much faster under 1.5.  Turns
out that after he changed some of the UBC tunables, he gained all of
the speed back.  So, chalk it up to bad defaults on underpowered machines.

If you really want to help solve the problem, investigate it and develop
a fix.  Putting one's head in the sand doesn't help anyone.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>