Mail Archives: djgpp/1996/12/19/01:47:00
On Mon, 16 Dec 1996, Peter Berdeklis wrote:
> In the FAQ it suggests that if interrupts occur at a high frequency that
> you should consider installing a real mode interrupt handler in addition
> to the protected mode handler. At the same time it states that a DPMI
> host always passes the int to prot. mode first, and only if unhandled
> does it pass it to real mode. So how does installing a real mode handler
> speed anything up? Even if you are temporarily in real mode (calling a
> DOS function), the interrupt still goes to pmode first, no?
Yes, it does, but this interrupt reflection costs you many CPU cycles,
because it involves a switch from real to protected mode (which eats up
many hundreds of cycles), and some heavy bookkeeping by the DPMI host.
When you install a real-mode handler, it handles the interrupt entirely
in real mode, so you save the overhead. Here's a relevant passage from
the FAQ:
* Allocate some conventional memory with `__dpmi_allocate_dos_memory' and
put the code of your handler there with the `dosmemput' function. (You
could also call one of the functions which allocate a real-mode
call-back, but these will cause a mode switch on every interrupt, which
you want to avoid; otherwise there is no point in installing a real-mode
handler, right?)
> While we're on the subject, is there any reason that enable() and
> disable() aren't inlined in the header file?
That's because you run in protected mode, where you generally are not
allowed to actually disable the interrupts. STI and CLI are priviledged
instructions in protected mode, which cause exception and are caught by
the DPMI host, or the memory manager, or Windows (depends on your system
configuration) which then does whatever it thinks is appropriate.
In DJGPP, `disable' and `enable' directly call the DPMI service which sets
and clears the *virtual* interrupt disable flag (which only disables
interrupts to your program, but not to the entire system), so they aren't
easily expressable as inline assembly. It also doesn't make sense IMHO,
since the DPMI call is quite heavy anyway.
- Raw text -