From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9709282338.AA14364@clio.rice.edu>
Subject: Re: [malcolm AT manawatu DOT gen DOT nz: Fork source code.]
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 28 Sep 1997 18:38:07 -0600 (CDT)
Cc: k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at, dj AT delorie DOT com,
        djgpp-workers AT delorie DOT com, malcolm AT manawatu DOT gen DOT nz
In-Reply-To: <Pine.SUN.3.91.970928184638.423O-100000@is> from "Eli Zaretskii" at Sep 28, 97 06:47:14 pm
Content-Type: text
Precedence: bulk

> Charles, what do you think about this?  

Under an IOPL 3 provider, STI/CLI work, are much faster than the 0x90x
calls, and you are much less likely to have bugs in the chip than
in anything Microsoft has written.

For non-IOPL 3 providers, these instructions trap, and must be emulated,
which is slower than 0x90x calls.  

So, it's DPMI provider dependent.  

We have seen bugs in the 0x90x calls under Windows - but we've also seen
bugs in the STI/CLI stuff too - just of a lesser nature.

I lean more towards the STI/CLI calls myself, since they are shorter,
clearer to read, and run at native speed under CWSDPMI ...

It is important to remember that IRET does *NOT* restore the interrupt
flag in all enviroments, which makes interrupt/exception handling a mess.
This is a bigger issue than the 0x900/sti stuff.