Mail Archives: djgpp/1999/03/02/10:55:15
On Mon, 1 Mar 1999, John S. Fine wrote:
> Eli seems to be saying that pmode only might be efficient
> enough. (Which I think still implies that both might be more
> effitient).
Yes, on both counts.
> 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.
> When a hardware interrupt
> occurs in V86 mode, the interrupt gate always takes you to
> pmode (I'm assuming task gates aren't used for IRQ's).
This depends on the memory manager. I don't know how different memory
managers actually work.
> So
> regardless of whether you were interrupted from V86 mode or
> pmode, you get to the same pmode code before any software
> choices occur.
This might or might not be true; the only way to know is to try and
experiment.
My point was that because of this uncertainty, and because installing a
real-mode handler is so much of a hassle, people shouldn't be doing that
unless they have a very good reason based on measurements.
> 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.
> so it is
> certainly possible that the code looks at what was
> interrupted and decides whether to try a V86 mode hook or
> a pmode hook first depending on what was interrupted, but
> that design doesn't sound useful or likely.
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.
- Raw text -