At 02:29 PM 11/23/2000 +0100, Wolfgang Solfrank wrote:
>Hi,
>
>While I can't argue that the trap handlers could stand quite some cleanup
>(and not only for SMP purposes I'd say), I've got some comments on your
>analysis:
>
> > The first is that the relative lack of use of the SPRG0-3 registers
> > by NetBSD.  Only SPRG1 is currently in use in trap_subr.S to store
> > away the SP (reg 1).
>
>I suggest you look again.  SPRG2 is used to save XER temporarily away,
>and SPRG2 & 3 are used during return from the traps to hold r2 & r3 contents.

Ya.  In FRAME_ENTER & FRAME_LEAVE.  But I think I can modify that to
only use 1 SPRG.

> > 3) (this just because it bugs me).  curpm is changed to paddr_t instead of
> >     struct pmap *, since it's the physical address of the current pmap 
> and then
> >     a bunch of casts can disappear.
>
>Hmm, not sure on this one.  (BTW, you probably mean pcb_pmreal and as
>a result curpm, as there currently is no cast involved when accessing
>curpm.)  Conceptually, with NetBSD/powerpc, there is no difference
>between physical and virtual addresses.  And there _are_ accesses
>to the pmap via the pcb_pmreal pointer, which would require a cast
>if you changed this.

Hmmm.  I only thought pmreal was used in the .S files.  I'll relook.

> > This should actually result in a slightly faster system since a number of
> > global references will become register indexed.
>
>Don't count on that.  The tempsave (et. al.) area is deliberately placed
>into locore, so it can be accessed without loading the high part of the
>address.  So actually accessing this area needs quite a bit more work
>than the current code:  you have to get yourself another free register
>for loading the cpu_info pointer out of SPRG3, then probably another one
>to load the tempsave pointer out of cpu_info.  Getting the intstk out
>of cpu_info will save you an instruction though (albeit only on
>interrupts, not on other traps).

Actually, in most instances, you don't.  Once you save R1 in SPRG1, you
can then store the cpu_info * ptr into R1, and CI_TRAPSAVE(1) to refer
to the tempsave area.

>In total, I'd be very much surprised if the system would get faster
>by this (assuming no other optimizations).

We can only hope.  Also, I'm trying group things together by cacheline
so that a minimum of extra data has to be loaded.
--
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message