Subject: Re: Use of SPRG0-3 on PowerPC & SMP issues
To: Wolfgang Solfrank <email@example.com>
From: Matt Thomas <firstname.lastname@example.org>
Date: 11/23/2000 14:01:29
At 02:29 PM 11/23/2000 +0100, Wolfgang Solfrank wrote:
>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
> > 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: email@example.com
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
Cupertino, CA Disclaimer: I avow all knowledge of this message