Date: Mon, 7 Jan 2002 12:21:59 -0700 From: Nate Williams <nate@yogotech.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Nate Williams <nate@yogotech.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15417.62807.556838.947343@caddis.yogotech.com> In-Reply-To: <Pine.SUN.3.91.1020107135541.812A-100000@pcnet1.pcnet.com> References: <15417.59947.662052.836634@caddis.yogotech.com> <Pine.SUN.3.91.1020107135541.812A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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 reason for conditionally saving it is because it would allow the most flexibility in the future. > 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 <getcontext> > 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? Nope, but you need to be able to get the FPU context saved in setcontext. Nate 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?15417.62807.556838.947343>