Subject: Re: HyperSPARC woes...
To: None <thorpej@nas.nasa.gov, abrown@eecs.harvard.edu>
From: Gordon W. Ross <gwr@mc.com>
List: port-sparc
Date: 10/19/1996 13:18:59
> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Fri, 18 Oct 1996 18:01:49 -0700
>
> On Fri, 18 Oct 1996 10:07:48 -0500
> Jon Buller <jonb@metronet.com> wrote:
>
> > 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...
>
> Actually, that's what happens if you have all of:
>
> options SUN4
> options SUN4C
> options SUN4M
>
> If you eliminate cpu types that you don't have, the code doesn't have
> to do all of the comparisons...
I still think it would make your code easier to read and maintain
if you just gave up on trying to make one kernel boot on anything.
I know Aaron finds that important, but I don't think many people
actually benefit much from having one kernel for all sparc boxes.
There are many places where you could just make variants of a file,
where one is used for sun4|sun4c and another for sun4m (thinking in
particular of the pmap code).
... Just my two cents, and I've said it before... (but it seemed
to be an appropriate time to restate the opinion)
Gordon Ross