From owner-freebsd-arch Fri Jan 25 16:17: 1 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 3826337B41D for ; Fri, 25 Jan 2002 16:16:54 -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 RAA23957; Fri, 25 Jan 2002 17:16:47 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0Q0Gk746863; Fri, 25 Jan 2002 17:16:46 -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: <15441.62830.180895.121111@caddis.yogotech.com> Date: Fri, 25 Jan 2002 17:16:46 -0700 To: Terry Lambert Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <3C51F492.CB0FB69E@mindspring.com> References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.com> <3C51F492.CB0FB69E@mindspring.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 > > > > You could stick in all sorts of funky hooks, but because threads can be > > > > intererupted at any time, the amount of checking that still needs to > > > > occur at runtime would make a compile-time solution un-necessarily > > > > slow. (MHO of course). > > > > > > Actually, the runtime checking is incredibly easy, if you > > > *know* the program can use the FPU: just switch totally > > > away from lazy binding at all. > > > > This is extremely inefficient for interpreted languages, where they > > *may* use the FPU, but it's not obvious until runtime whether or not > > they *will* use the FPU. (FPU usage is till a rarity in comparison to > > the total runtime of the program.) > > I think the way I would handle this for Java, for example, > is to do the swicth when the JNI code for the FPU access > code is loaded. What JNI code? It's an interpreted language, so you just make 'normal' function calls as you would a normal program. Are you implying that we hack up the Java code to set a flag saying we've used the FPU anytime a call is done? How do we know when to clear this flag? This is a complete and utter hack (IMO). > > And, when you have threaded interpreted languages it gets even more > > exciting, since now you take the hit for every userland context switch, > > even though you probably didn't use the FPU (since you didn't know). > > This is the real problem: you can't safely do mixed FPU and > non-FPU access, if your threads can move between processors > without user space threads scheduler interaction in this case. > > I really don't want to mandate that that happen, for obvious > reasons. But it will, whether you like it or not. Part of the responsibility in being a 'general purpose OS' is that you don't get to dictate what people use it for. [ SNIP ] > Hence my punting to "optimize later". 8-(. Otherwise known as not having a complete solution to the problem, hence not having a solution at all. :( > > > The reason it exists at all is "in case someone uses the FPU". If you > > > know they won't, it makes the rest of the code run faster, which is > > > probably an acceptable tradeoff. > > > > I still don't consider this a workable solution, since there are as many > > exceptions as there are standard cases. > > Unfortunately, we can't fix the base problem, which is > "delayed exception signalling on x86 FPUs sucks". 8-). On the money! We are in violent agreement for once. :) :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message