Mail Archives: djgpp/1999/03/02/16:16:24
Eli Zaretskii wrote:
> > When you are running "real mode" code in a DPMI program,
> > you are not every actually running in real mode (are you?).
> > You are running in V86 mode.
>
> Not necessarily, it depends on the machine configuration. If you run
> DJGPP without any memory manager (no EMM386 or QEMM, no Windows), or with
> HIMEM alone, you *are* in real mode. Memory managers usually switch the
> CPU to V86.
. . .
> > That pmode code is deap inside the kernel of Windows or
> > some stand-alone DPMI provider (or similar),
>
> More often it is inside a memory manager, unless you run Windows.
I never had that good an understanding of the boundaries between
the extender and the DPMI server and the memory manager. If you run
CWSDPMI without EMM386, then CWSDPMI is responsible for things that
otherwise EMM386 would handle. I think you are saying that CWSDPMI,
then uses true real mode for DOS calls, rather than using V86 mode.
I think using true real mode is a bad design for many reasons, but
if CWSDPMI actually works that way, then I certainly understand why
having both real mode and pmode hooks for an interrupt would be
needed for *best* performance.
If CWSDPMI really uses real mode that way, and I was seting up a
system to service 20Hz interrupts in djgpp, I think I would make
sure QEMM or EMM386 or something was loaded first. Those certainly
have their own overhead, but I think the problems in either servicing
the interrupts in real mode, or reflecting them to pmode, would
outweigh that overhead.
> Interrupt reflection from real (or VM86) mode to protected mode is not
> that easy. The mode switch itself eats up a lot of cycles, even from
> V86, and there are also other chores, like setting up the stack for the
> client etc.
What do you mean by "even from V86"? Reflecting an interrupt from
real mode to protected mode is a complex software operation; Enough
so that it would almost always be a better design to avoid using
real mode at all (use V86 instead).
Reflecting an interrupt from V86 mode to pmode, is not a software
task at all. If a hardware interrupt occurs in V86 mode, the CPU
delivers it in pmode. It takes a few extra cycles to read the
stack pointer from the TSS and to write extra context on the stack,
but that overhead is trivial compared to software controlled switches
between pmode and real mode.
One of my projects runs mainly in V86 mode on a 50Mhz 486. All
interrupts are in pmode and it often sevices interrupts well over
20Khz for sustained periods. On a 486 with a write-through cache,
it was very hard (but possible) to get acceptable performance in
such conditions. Same speed 486 with a write back cache makes it
easy. With a write back cache the hardware mode switches to and
from V86 mode don't even make the list of the top twenty places
that CPU time is spent (during interrupt servicing at over 20Khz).
I assume whoever started this was planning to use a better CPU
than my 50Mhz 486, so the mode switches to and from V86 mode can
be ignored as a performance factor.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/
- Raw text -