Date: Thu, 04 Mar 2004 17:31:07 +1000 From: Peter Grehan <grehan@freebsd.org> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point Message-ID: <4046DB3B.9000604@freebsd.org> In-Reply-To: <Pine.GSO.4.10.10403040141100.22656-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10403040141100.22656-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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. later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4046DB3B.9000604>