X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
From: "Gerrit van Niekerk" <gerritvn AT gpvno DOT co DOT za>
Organization: GPvNO
To: djgpp AT delorie DOT com
Date: Tue, 22 Jan 2008 09:52:55 +0200
MIME-Version: 1.0
Subject: Re: RM/PM ISR
Message-ID: <4795BCF7.26396.F2F9F52@gerritvn.gpvno.co.za>
In-reply-to: <fn35k9$cjo$1@aioe.org>
References: <479518F6 DOT 7820 DOT CAEFE78 AT gerritvn DOT gpvno DOT co DOT za>, <fn35k9$cjo$1 AT aioe DOT org>
X-mailer: Pegasus Mail for Windows (4.41)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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