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