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...

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.

If this capability does not currently exist, perhaps I can work on
it, after I get my Distributed Operating Systems Class Research Paper(tm)
written, (Due end of Oct.) and the product at work goes from
primarily development to primarily support (next month or two).

Jon