From owner-freebsd-arch Mon Jan 7 11:44: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3625637B416 for ; Mon, 7 Jan 2002 11:43:51 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA13397; Mon, 7 Jan 2002 12:43:43 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g07Jhgt98567; Mon, 7 Jan 2002 12:43:42 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15417.64110.441186.451573@caddis.yogotech.com> Date: Mon, 7 Jan 2002 12:43:42 -0700 To: Daniel Eischen Cc: Nate Williams , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: References: <15417.62807.556838.947343@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > > 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