Date: Mon, 10 Apr 2000 08:41:29 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Kalum Somaratna aka Grendel cc: djgpp AT delorie DOT com Subject: Re: HARDWARE INTERRUPT HANDLING BY CWSDPMI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.