Date: Mon, 7 Jan 2002 14:38:46 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Nate Williams <nate@yogotech.com> Cc: 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: <Pine.SUN.3.91.1020107142404.812B-100000@pcnet1.pcnet.com> In-Reply-To: <15417.62807.556838.947343@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jan 2002, Nate Williams wrote: > > 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. Well, that's what I mean. If somewhere else in the application there was a setcontext that returned to the getcontext above... What I'm asking is, is there any FP state (other than the FP control word which does get saved/restored), from before the getcontext call that needs to be reloaded after the call, or does the compiler assume that state may have been changed by the call itself? What happens if the getcontext call above gets replaced by another function call that does more FP stuff? It seems like any state would need to be saved across the function call by the compiler anyways. -- Dan Eischen 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?Pine.SUN.3.91.1020107142404.812B-100000>