> yes, i was actually already aware of lcc.

> The problem is, i don't have 6 months of "compiler development" time
> to throw at it.  Other than its obvious deficiencies, and my lack of
> time to correct them, in my opinion, it's a better choice.

I keep pecking at lcc now and then but it needs more solid
time.  I bring lcc up in the hope that *some* kind soul gets
conviced enough to work on it.

Actually it is not as bad as it sounds.  Making it work for
the kernel on the SPARC/MIPS platforms should be a few day's
work.  For the 386 kernel it is a bit more work.  But if we
cut out -PIC intially, most of the work needed is of
massaging sort to make lcc talk to other tools.  The first
step is to bring up Icon interpreter/compiler since it is
used for automatically generating the backend.

On the NetBSD side if the compiler used to make the kernel
(and in general, other tools needed to make the kernel) live
in their own tree, it'll be easier to introduce a new
compiler for either the kernel or the userland.  The kernel
tools can live in $SYSGEN/{bin,lib} or whatever.

>                                         It's also worth noting that
> /usr/src/gnu is currently 33M, ...

To me the current size of gcc is a bigger concern than the GPL.
But it is a hard habit to break....

Bakul