Date: Mon, 7 Apr 1997 13:39:46 +0300 (IDT) From: Eli Zaretskii To: Ramesh Nallur cc: djgpp AT delorie DOT com Subject: Re: Interrupts (Hardware) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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