Mail Archives: djgpp/1999/04/29/10:20:54
On Thu, 29 Apr 1999, Alberto Chessa wrote:
> This is an OT question but actually I do not know a better NG for it.
This issue is not off-topic here.
> It is possible, running under CWSDPR0, to directly manage CPU interrupt
> flag via CLI and STI (and IRET, POPF) ?
Do you really need CWSDPR0 (for reasons other than CLI and STI)? Because
CLI and STI are actually faster for IOPL 3 DPMI host (at least most of
them), since they run at native speed. In contrast, a ring-0 host would
typically trap CLI and STI and emulate them with code that takes eons to
execute.
> Are these instruction slow, that is are they trapped by the VM monitor ?
It depends on the VM monitor. On plain DOS and with CWSDPMI, they are
not trapped.
> The DJGPP function disable()/enable(), implemented via
> dpmi_get_and_disable/enable_interrut(), reflect virtual interrupt state
> on the CPU interrupt flag ?
If you are using DJGPP v2.02, then `disable' and `enable' do NOT call the
DPMI functions, they emit CLI and STI in inline assembly (see below).
This is the fastest and the most reliable method of doing that, even
though some DPMI servers, notably Windows, will still trap them and
emulate the interrupt flag. However, the DPMI functions aren't faster on
Windows, and have more bugs in their implementation, so v2.02 switched to
STI/CLI.
Here's the source of `disable' from the v2.02 library (I'd really
suggest to download the library sources if you want to mess with these
subtleties, btw):
int
disable(void)
{
/* return __dpmi_get_and_disable_virtual_interrupt_state(); */
int rv;
asm("pushf; popl %0" : "=g" (rv));
rv = (rv>>9) & 1;
asm("cli");
return rv;
}
- Raw text -