Date:	Mon, 10 Apr 2000 08:41:29 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Kalum Somaratna aka Grendel <kalum AT lintux DOT cx>
cc:	djgpp AT delorie DOT com
Subject:	Re: HARDWARE INTERRUPT HANDLING BY CWSDPMI
In-Reply-To:	<Pine.LNX.4.10.10004091901040.1090-100000@darkstar.grendel.net>
Message-ID:	<Pine.SUN.3.91.1000410084111.19649G@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 9 Apr 2000, Kalum Somaratna aka Grendel wrote:

> On Sun, 9 Apr 2000, Eli Zaretskii wrote:
> 
> > A DJGPP program indeed incurs additional overhead, because under DPMI,
> > all hardware interrupts are reflected to protected-mode handlers
> > first, and only if unhandled, they are passed to real-mode handlers.
> > The mode switch that this involes takes up hundreds of CPU cycles.
> > 
> 
> In such a case like handling com port interrupts, installing *both* a real
> mode and a protected mode handler should avoid this overhead.

No, it won't, at least not with all DPMI providers.

A real-mode handler helps to avoid the overhead of the reflection from
real to protected mode, which happens when the interrupt is raised
while the CPU is in real mode (e.g., inside a DOS call), while the
handler is a protected-mode one.

However, in this case, we have the opposite situation: the handler is
a real-mode one (a real-mode TSR), while the CPU stays in protected
mode most of the time because a DJGPP program runs in the foreground.
A real-mode handler worn't help here, since most DPMI servers will
call the protected-mode handler first, and only then reflect to the
real mode.

- Raw text -