X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Date: Mon, 10 Dec 2001 00:04:32 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <3995-Mon10Dec2001000430+0200-eliz@is.elta.co.il> X-Mailer: emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com, rich AT phekda DOT freeserve DOT co DOT uk In-reply-to: <10112092038.AA14146@clio.rice.edu> (sandmann@clio.rice.edu) Subject: Re: libemu and profiling (LONG) [Was: Re: Building a profiled version of References: <10112092038 DOT AA14146 AT clio DOT rice DOT edu> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) > Date: Sun, 9 Dec 2001 14:38:00 -0600 (CST) > > > double d = atan(0.123); > > > > Using the math co-pro (387 not set or set to y) gives a result of > > 0.122385; using a patched emu387.dxe gives a result of 0.1. Shouldn't the > > results be the same or at least a little closer? > > The accuracy of the emulator in some cases isn't very good - I don't know > if this is such a case. WMEMU is more accurate. The accuracy of emu387 got boosted quite a bit in preparation for v2.03. It is no longer the case that WMEMU is so much more accurate; in most cases, the two are comparable. We even emulate the most popular numerical exceptions like an x87 would. About the only thing WMEMU still does better is to emulate the flags and the other ancillary behavior of a true x87. Still, there are a few pathological cases where emu387 could return inaccurate results (at some point, I got bored chasing obscure arguments and rewriting Intel manuals in C++ ;-). That's why I asked Richard to try a few more argument values, and see if he has hit a singularity or a real bug. Oh, one other thing Richard should make sure _very_ carefully is that he really is running the right emu387.dxe. I've been down that alley, chasing non-existent bugs, too many times... > The hardware flag in the chip got left in the emulate mode. > You may have confused the DPMI provider (they really don't like allowing > FP emulation. Last chip not to have FP was a 486SX - and most of those > aren't supported under newer Windows. So this code never gets used or > tested). I used it quite a bit when I worked on v2.03, to fix the emulator bugs and test libm.a. Our startup code only resets the emulation flag to its ``normal'' hardware state if the application is invoked with, so if you don't rerun some program with 387 not set at all, the emulation bit doesn't get reset. I think this isn't a bug, but a feature: when you have 387=y, the program shouldn't second-guess the user, it should begin issuing x87 instructions right away. Otherwise, some funky environment could defeat the auto-detect code, and cause it to fall back on emulation. Setting 387=y forces it to use x87, no questions asked. That setting is a promise from the user that the x87 is available; Richard was breaking that promise...