Subject: Re: HyperSPARC woes...
To: Jon Buller <jonb@metronet.com>
From: Aaron Brown <abrown@eecs.harvard.edu>
List: port-sparc
Date: 10/18/1996 19:53:25
> Aaron Brown <abrown@eecs.harvard.edu> writes:
> 
> > The big problem with fixing these problems is in getting them to coexist 
> > with support for other machines. Consider, for example, the handler for
> > an asynchronous memory fault trap. In assembler, within a trap window,
> > you have to (1) test the CPU type/model (2) jump to the appropriate piece
> > of code (3) read the appropriate registers, in the right order, with 
> > the right bits set in the MMU to avoid other faults (4) pass it up to a
> > CPU-specific C-level handler that knows how to interpret the stuff read
> > in in the assembly routine.
> > 
> > 	"Ugh"
> 
> That sounds real slow, does EVERY SPARC kernel do that on ALL traps?
> It sounds like a config option that would inline the code for MY machine
> and eliminate the code for all others would be significantly faster.
> (All this from someone who has not looked at the code, but did get
> an ELC a few months ago and is currently running said code.)
> 
>      option I_HAVE_AN_ELC_WITH_A_XXX_PROCESSOR_YYY_CACHE_ZZZ_ESPCHIP...

The GENERIC kernels do things like this. There is really no good way around
it; we do maintain 3 trap tables that are selected at bootup to at least
make traps relatively fast.

However, there is a good deal of conditional goop that runs when you are
using the GENERIC kernel. I'd recommend building one with only "options
SUN4C" in your case; removing the SUN4/SUN4M options will speed up things
like pmap (and thus VM).

I suppose it would be possible to have options to specifically enable only
one version of the code for various CPU revisions, although I'm not sure
what that will buy you; most of the weirdness is off the common case code
paths (I mean, if you've got an async. memory fault, saving 10 cycles or so
is not very useful...).
 
> I only have one machine, and I don't really care if I can move my
> kernel to another SPARC without rebuilding it.  I do, however, want
> my kernel to run relatively as fast as possible, and be relatively
> as small as possible.  I can see the use of such general routines for a
> generic kernel, and would view the existence of such code as critical,
> especially when grabbing a tar ball and installing.  But I want
> to be able to put in a Faster, Smaller, Better(R) version for my
> machine once I can run well enough to rebuild the system.

Well, the certainly don't run the GENERIC kernel. Hack out support for
other machines, devices you don't use, etc. from your config file; remove
debugging/diagnostic options. The GENERIC kernels tend to be large and
slow, but I think it is important and a Good Thing that they exist and will
boot on lots of machines...right now the same binary will boot everything
from a lowly Sun4 up to a fancy Sun4m. A lot of the work on the sun4m port 
was getting this to work--not a trivial task when you want the same kernel
to support two rather different MMUs!

--Aaron