Date: Wed, 1 Sep 1999 15:07:36 +0200 (METDST)
Message-Id: <199909011307.PAA20209@tyr.diku.dk>
From: Morten Welinder <terra AT diku DOT dk>
To: eliz AT is DOT elta DOT co DOT il
CC: sandmann AT clio DOT rice DOT edu, dj AT delorie DOT com, djgpp-workers AT delorie DOT com
In-reply-to: <Pine.SUN.3.91.990901122128.25D-100000@is> (message from Eli
	Zaretskii on Wed, 1 Sep 1999 12:21:51 +0300 (IDT))
Subject: Re: FWAIT emulation in emu387.cc
References:  <Pine DOT SUN DOT 3 DOT 91 DOT 990901122128 DOT 25D-100000 AT is>
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


   As you see, here FWAIT is after FSTCW.  Do I understand correctly that
   this is *not* the case you are describing?

Correct.  As an aside, FWAIT is a prefix (and indentical to the WAIT
prefix) -- what does it mean standalone?

   The only way I can understand this is that Windows sets the two bits
   which Intel says will cause FWAIT to trigger the coprocessor not
   present exception.

Speculation: Maybe Windows run another process after emulating the
previous instruction.  That would cause the TS flag to be set.

   I'm interested in the value of EIP when FWAIT *does* trigger an
   exception.  Is there any possibility that when this happens, EIP
   would point to something other than the instruction that triggered the
   exception, i.e. FWAIT itself?

Short of prefixes, I do not think so.

Morten