Date: Mon, 7 Jan 2002 12:43:42 -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.64110.441186.451573@caddis.yogotech.com> In-Reply-To: <Pine.SUN.3.91.1020107142404.812B-100000@pcnet1.pcnet.com> References: <15417.62807.556838.947343@caddis.yogotech.com> <Pine.SUN.3.91.1020107142404.812B-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. > > > 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... I think I understand what you are asking. Are you asking if there is application specific context that needs to be saved, such as GC state or somesuch? Or, am I truly confused? > 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? In restrospect, I don't believe we switch contexts w/out a thread switch, so it may be adequate to only worry FP context during signals. 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.64110.441186.451573>