Date:	Thu, 19 Dec 1996 08:32:09 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Peter Berdeklis <peter AT atmosp DOT physics DOT utoronto DOT ca>
cc:	djgpp AT delorie DOT com
Subject:	Re: Question about hardware interrupts...
In-Reply-To:	<Pine.SGI.3.91.961216105301.3036A-100000@chinook.physics.utoronto.ca>
Message-ID:	<Pine.SUN.3.91.961219082005.24763E-100000@is>
MIME-Version:	1.0

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 -