Mail Archives: djgpp/2008/01/22/02:55:10
On 21 Jan 2008 at 17:19, Rod Pemberton wrote:
> "Gerrit van Niekerk" <gerritvn AT gpvno DOT co DOT za> wrote in message
> news:479518F6 DOT 7820 DOT CAEFE78 AT gerritvn DOT gpvno DOT co DOT za...
>> Looking at the GDB serial port driver SER-GO32.C, I notice that
the RM ISR is
>> implemented as a _go32_dpmi_allocate_real_mode_callback_iret to
>> the PM ISR.
>> My question: Is there really an advantage in implementing a RM
>> ISR this way? An interrupt in RM will result in a switch to PM
>> which would have happened anyway if there was no RM ISR and the
>> interrupt got reflected to PM. Anything I'm missing?
>
> This part:
>
> > An interrupt in RM will result in a switch to PM
> >
>
> No. DJGPP only uses DPMI, not a DOS-Extender.
>
> The only software interrupts "reflected" from RM to PM by DPMI are int 1ch,
> int 23h, int24h. See 2.4.2 of DPMI 0.9 specification
>
> The only PM interrupts "trapped" by DPMI are int 21h ah=4ch, int 2fh,
> int31h.
>
> All hardware interrupts, i.e., IRQ's are "reflected" from RM to PM, call all
> PM handlers, and then the interrupt is "reflected" back to the RM handler.
> The specification requires IRQ0 to IRQ7, and IRQ8 to IRQ15 to be mapped to
> their default interrupts, int 08h to int 0fh, and int 70h to int 77h,
> respectively. See 2.4.1 of DPMI 0.9 specification.
Rod, you are confirming my statement about h/w interrupts getting
reflected from RM to PM. I am talking only of h/w interrupts, not s/w
interrupts. So my original question (expanded for more clarity)
remains unanswered: Is there really an advantage in implementing a RM
ISR this way vs just implementing the PM ISR?
As I understand it, this is actually going to be *worse*, the ISR is
going to be entered in PM and then called again from RM always
forcing a mode switch even if the interrupt happened in PM.
Gerrit
- Raw text -