Date: Fri, 25 Jan 2002 17:16:46 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Williams <nate@yogotech.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, arch@FreeBSD.ORG Subject: Re: KSE question Message-ID: <15441.62830.180895.121111@caddis.yogotech.com> In-Reply-To: <3C51F492.CB0FB69E@mindspring.com> References: <3C51D0B6.F6E04EBC@mindspring.com> <Pine.SUN.3.91.1020125164325.24428A-100000@pcnet1.pcnet.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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15441.62830.180895.121111>