delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/06/10/06:32:28

Message-Id: <5.0.2.1.2.20020610105441.009e8500@pop.gmx.net>
X-Sender: martinSteuer AT gmx DOT de@pop.gmx.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 10 Jun 2002 11:31:49 +0200
To: djgpp AT delorie DOT com
From: Martin Steuer <martinSteuer AT gmx DOT de>
Subject: Re: Question about djgpp's int-wrapper
Mime-Version: 1.0
Reply-To: djgpp AT delorie DOT com

Charles Sandmann (sandmann AT clio DOT rice DOT edu) wrote:

 >We've recently found out that Windows 2000 seems to ignore the DPMI 0x9
 >call to block interrupts (and this interrupt is actually recommended
 >in the spec to avoid the emulation overhead of STI/CLI).

This directs my view to the enable()/disable() implementations, there we 
leave on the IF but not on the virtual one.
As you say Win2k ignores the DPMI Function calls for the virtual interrupt 
flag, so the implementation of disable() is "half right" for Win2k, it at 
least disables Virtual Interrupts to the program but doesn't return the 
correct state of the virtual interrupt flag.
But on Win9x we should use calls to 
__dpmi_get_and_disable_virtual_interrupt_state() for efficiency. But i 
think on those systems there seams to be no real Virtual Interrupt Flag at 
all, at least on Win95 I can disable interrupts and the whole system is 
blocked... so there is not much to worry about enable()/disable() there, in 
this case it is really only a matter of efficiency.

The conclusion: there is no overall workaround and we can't just blindly 
leave on enable()/disable() in Win2k during HW-Access sequences.
But for hardware interrupt handlers there is no problem with issuing a 
'sti' before your 'iret', if you chain then you should just let the 
interrupts disabled.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019