|
delorie.com/djgpp/doc/dpmi/ch4.4.1.html
|
search
|
Virtual Interrupts
Under many DPMI hosts, interrupts will always remain enabled in
protected mode (i.e. the interrupt flag will be set at all times) to
allow preemptive multitasking. Such hosts will maintain a virtual
interrupt state for each virtual machine, trapping the execution of
instructions that ordinarily affect the hardware interrupt flag and
adjusting the client's virtual interrupt flag accordingly. When the
virtual interrupt flag is cleared by the client's execution of
CLI or call to DPMI function Int
31H 0900H, the program will not receive any hardware interrupts
until it sets the flag again with STI or calls Function 0901H. DPMI clients should not
use the PUSHF instruction to examine their interrupt status.
This is because PUSHF pushes the real processor flags onto
the stack, which do not reflect the state of the client's virtual
interrupt flag. Similarly, clients cannot use IRET(D) or
POPF to alter the interrupt flag, because these instructions
access the physical interrupt flag and are ignored by the CPU due to
the client's privilege level.
Example: The following source code demonstrates how a client
would disable virtual interrupts prior to entry to an
interrupt-critical section of code, then restore the virtual interrupt
flag to its previous state at the end of the critical section:
mov ax,0900h ; get previous virtual interrupt
int 31h ; flag and disable interrupts
push ax ; save value 0900H or 0901H
.
. ; interrupt-critical code goes here
.
pop ax
int 31h ; restore previous interrupt flag
If the client already knows (or does not care about) the previous
state of the virtual interrupt flag, it can use CLI and
STI instead of DPMI functions
0900H and 0901H. The programmer
should assume that the execution of either of these instructions will
be slow.