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" <eliz AT is DOT elta DOT co DOT il>
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

> 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...

- Raw text -