On Thu, Nov 23, 2000 at 02:29:25PM +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.
> 
> > 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.
> 
> > 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).
> 
> In total, I'd be very much surprised if the system would get faster
> by this (assuming no other optimizations).

Well, for different reasons, I can make good use of a SPRG0 (say) carried
cpu area with all the xxxsave stuff... see my old message in port-powerpc.

(On Amiga, the trap handlers are too far away from any probable locore area.
 Actually, the exact address will most likely change at kernel load time.)

Regards,
	-is