Re: Use of SPRG0-3 on PowerPC & SMP issues

[Matt Thomas <matt%3am-software.com@localhost>]

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@localhost
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message