User-space context switch and floating-point

Daniel Eischen eischen at vigrid.com
Thu Mar 4 07:28:20 PST 2004


On Thu, 4 Mar 2004, Peter Grehan wrote:

> > So if the caller saves the registers before pthread_mutex_lock(), why
> >  do they also need to be saved by _thr_getcontext (which may be a 
> > result of pthread_mutex_lock() in this example)?
> 
>   I was a bit vague. Here's relevant text from the SVR4 PPC ABI:
> 
> "Registers r1, r14 through r31, and f14 through f31 are nonvolatile;
> that is, they "belong" to the calling function. A called function shall
> save these registers  values before it changes them, restoring their
> values before it returns. Registers r0, r3 through r12, f0 through f13,
> and the special purpose registers CTR and XER are volatile; that is,
> they are not preserved across function calls."
> 
>   and:
> 
> "r3 through r10 and f1 through f8:
> These sets of volatile registers may be modified across function
> invocations and shall therefore be presumed by the calling function to
> be destroyed. They are used for passing parameters to the called
> function; see Parameter Passing in this chapter. In addition, registers
> r3, r4, and f1 are used to return values from the called function, as
> described in Return Values."
> 
>   So as a context-save function, you have to assume that f14-31 are being
> used by the caller and save them. Problem is, these regs are 64-bits
> on PPC, touching them will cause an FP trap and from then on force
> full kernel FP save/restore for that proc's td, which is big performance
> hit for the majority of non-FP threads userland threads.

Yes, for the first time.  Thread switches that follow won't cause
the trap, until the process (kernel thread really) gets swapped
out/interrupted.

I think the x86 is similar when saving/restoring the FP control
world.

>   The Altivec register file is a bit better since it has a register to
> inform context switch code which of the 32 128-bit registers are in
> use.

-- 
Dan Eischen



More information about the freebsd-threads mailing list