Mail Archives: djgpp/2000/04/10/10:36:44
On Mon, 10 Apr 2000, Eli Zaretskii wrote:
>
> 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.
Hmm.... I was commenting on a generic protected mode program that has to
do com port handling.
Would it be possible then for him to rewrite the 16-bit TSR as a
protected mode TSR with a real mode handler too..then wouldn't that avoid
the problem...
Grendel
Hi, I'm a signature virus. plz set me as your signature and help me spread
:)
- Raw text -