Date: Tue, 8 Jan 2002 16:02:23 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dan Eischen <eischen@vigrid.com> Cc: <arch@FreeBSD.ORG> Subject: Re: Getcontext resolution? Message-ID: <20020108155143.W3532-100000@gamplex.bde.org> In-Reply-To: <3C3A5FDC.23866673@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jan 2002, Dan Eischen wrote: > I'll also enable full save of the FP state in getcontext(). The > optimized code will be commented out (i386 version): > > /* > * XXX - Do we really need to save floating point registers? > * > * This is an explicit call to get the current context, so > * shouldn't the caller be done with the floating point registers? > * Contexts formed by involuntary switches, such as signal delivery, > * should have floating point registers saved by the kernel. I think this is viable. It's essentially what the i386 setjmp() does (for a smaller context). > * As of this writing, the kernel doesn't yet save the FPU state > * on signal delivery, so a setcontext on the interrupted context > * may yield incorrect results regardless. > */ > #if 0 > fnstcw MC_FP_CW_OFFSET(%edx) /* save control word */ > movl $UC_MC_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext valid, no FP */ > #else > fnsave MC_FP_REGS_OFFSET(%edx) /* save FP regs */ > movl $MC_FP_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext and FP valid */ > #endif Even the fnstcw will cause a trap the the kernel on i386's if the state isn't already in the FPU, so little or negative might be gained relative to a syscall that can sometimes just copy the state. This has proved to be an insignificant problem for setjmp(). Perhaps all of the i386 optimizations are backwards anyway :-). Memory bandwidth might be the bottleneck with fast CPUs. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020108155143.W3532-100000>