Date: Fri, 25 Jan 2002 16:30:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Williams <nate@yogotech.com> Cc: 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: <3C51F89E.78DAD01D@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> <15441.62830.180895.121111@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > 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? You never clear it, once it is set. > This is a complete and utter hack (IMO). Yes. See my reply to myself, for a possible workaround. > > > 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. A "might use FPU" flag is about as general purpose as you can get and still segregate non-FPU from FPU use. The only other alternative is to not segrgate it at all, and then you incur the overhead everywhere, rather than just in programs that offend the gods of bad FPU design. > [ 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. :( It maps the problem space, so it's a complete solution. I admit is a far cry from an optimal solution, if you risk the FPU at all, since you pay to get into the part of the theme park where the roller coaster is located, whether or not you actually get on the roller coaster, or just ride the bumper cars. One way around this would be to compile your Java programs to native code, but that's ugly, too, and has corner cases when you grab serialized objects out of a directory or whereever, and have to fall back to the JVM to access the member functions, which might use the FPU. 8-(. > > > > 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. :) :) :) :) Cool! Let's just dike the thing out! I know, we can compile the FPU emulation library into user space, and not use the hardware FPU at all. Then we can fix the emulated FPU, and the problem goes away. 8-) 8-) 8-). -- Terry 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?3C51F89E.78DAD01D>