Mail Archives: djgpp/1997/04/07/06:49:00
On Sun, 6 Apr 1997, Ramesh Nallur wrote:
> but my question is slightly different, I want to exactly know
> how interrupts are handled by the DPMI server?.
It would help if you also tell why do you need to know that. This
issue is immensly complex and full of gory details; knowing what
practical use do you have in mind will help to present manageable
amount of info without losing important details.
> When a program runs in PM the IDT is replaced and the interrupts are
> caught here. But I think the hardware interrupts are not caught here. As I
> understand from the notes they are caught in the real mode.
The IDT is not ``replaced'', at least not necessarily. The DPMI host
usually changes some entries in the IDT to point the hardware
interrupts to its own handlers, but AFAIK this is so it could reissue
the interrupts to real-mode handlers if the DPMI client (the DJGPP
program you run) didn't install its own handler. There is no general
rule which says that you need to do anything with the IDT in protected
mode, exactly as you don't need to do anything with the real-mode
interrupt vector table when you run a real-mode program. The DPMI
host does that because these are specifics of the DPMI environment,
where protected-mode programs run on top of real-mode DOS. Take the
timer interrupt as an example. If it happens in protected mode, and
the DJGPP program didn't install a handler for it, it needs to be
reflected to the real-mode handler (in the BIOS), or else your machine
will be wedged. But this is specific to the DOS operation, there's
nothing in PM per se that requires such reflection to real mode.
> But how is
> this possible when the IDT has been replaced. And if they are caught in
> the RM, should not be there a switching of modes for every hardware
> interrupt? There have been lot of notes about reflecting the RM interrupt
> to PM. What exactly does reflecting mean?
Remember that a hardware interrupt can happen when the CPU is either
in protected or in real mode. The DPMI spec requires that hardware
interrupts should be always passed to a PM handler, even if they
happen when the CPU was in real mode (like when your program called
some DOS function). This reflection is the job of the DPMI host, and
it indeed involves a mode switch. The DPMI host usually installs a
real-mode interrupt handler for hardware interrupts (using the same
technique as any real-mode program does); these handlers switch the
CPU to protected mode, call the PM handler which was installed for
that interrupt by the DJGPP program, then switch to RM again when the
handler does an IRET.
To prevent overhead of mode switches, most DPMI hosts hook hardware
interrupts in RM only if your program actually installs a PM handler;
otherwise they leave them to be handled in real mode. So the
expensive mode switch usually only happens if your program installs a
PM handler for a hardware interrupt.
Once again, this is all very specific to the DPMI environment, it
doesn't need to happen just because you are running the CPU in PM.
> Does it mean that actually the
> table at 0000:0000 is used when a hardware interrupt occurs in PM?
No. The table at 0000:0000 is the real-mode interrupt vector table.
It is only used when a hardware interrupt occurs while the CPU is in
RM. If the DPMI host hooks the interrupt in RM (see above), the
relevant table entries are set to call code inside the DPMI host.
When the hardware interrupt occurs in PM, it is handled using the PM
IDT (Interrupt Descriptor Table) which is an entirely different
structure specific to protected mode.
> Has it got to do anything with setting up the PIC?
AFAIK, the PIC is not reprogrammed in DPMI, or at least it doesn't
*have* to be reprogrammed. It works as usual, activating the INT line
of the CPU when one of the IRQ lines is activated. What happens when
the INT line goes ON, however, depends on whether the CPU is in RM or
PM, see above.
> Why cant I just overwrite an IDT entry in PM and expect interrupts to be
> caught?
I think if you do that, the reflection of the interrupts from RM might
be broken. Using the appropriate DPMI function makes your program
play by the rules.
Why would you need to do that, anyway?
> I looked at the code for the __dpmi_set_protected_mode_int_vec and I saw
> that there is some restoration or reflection of the RM handlers
> (0000:0000). Why is this being done?.
This is the entire code of the function that sets PM interrupt
handler. Where do you see anything that's connected with RM handlers
or 0000:0000?
#define USE_EBX
#include "dpmidefs.h"
.text
FUNC(___dpmi_set_protected_mode_interrupt_vector)
ENTER
movb ARG1, %bl
movl ARG2, %eax
movl (%eax), %edx
movw 4(%eax), %cx
DPMI(0x0205)
xorl %eax,%eax
LEAVE
- Raw text -