From owner-freebsd-arch Mon Jan 7 11:19:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3A1C937B402 for ; Mon, 7 Jan 2002 11:19:21 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g07JIDKP005102; Mon, 7 Jan 2002 14:18:13 -0500 (EST) Date: Mon, 7 Jan 2002 14:18:12 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15417.59947.662052.836634@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 7 Jan 2002, Nate Williams wrote: > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > can be efficiently done since this user-level function will not know if > > > the current context has touched the FPU yet.. > > > > Neither does the kernel, does it? I thought I saw comments in the > > kernel (was it alpha?) about it being too bad that we couldn't tell > > if the FPU was used. In libc_r, we currently only save and restore the > > FP state when the context is generated from a signal handler (or perhaps > > in the case of KSEs, when the thread was preempted). > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > thread switch, since it has no way of knowing if the thread was doing FP > context. Is there a way to force get/setcontext to always/conditionally > save the FP context, for applications that either know they need to have > it saved? Sure, you can always save the FP context, but you can't really conditionally save it without changing the interface for these functions or adding another set of functions that save the FP context. The FP context is what I'm most unsure about. Forget about contexts generated by signals for the moment. If you have code that does something like: f1 = 1.245 * f2; f3 = f1 * (float)getcontext(&uc) * 2.5; f5 = f3 * 3.14159; which disassembles to something like: push %ebp mov %esp,%ebp sub $0x68,%esp flds 0x804fde0 fstps 0xfffffff0(%ebp) flds 0xfffffff0(%ebp) fldl 0x804fde8 fmulp %st,%st(1) fstps 0xfffffffc(%ebp) add $0xfffffff4,%esp lea 0xffffffc0(%ebp),%eax push %eax call 80482fc add $0x10,%esp mov %eax,%eax mov %eax,0xffffffac(%ebp) fildl 0xffffffac(%ebp) fmuls 0xfffffffc(%ebp) fldl 0x804fdf0 fmulp %st,%st(1) fstps 0xfffffff8(%ebp) [...] This is a perverse example of how one would use getcontext. I'm not familiar with the FPU, but is there any state that needs to be saved across the getcontext call? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message