X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: RM/PM ISR
Date: Tue, 22 Jan 2008 16:35:24 -0500
Organization: Aioe.org NNTP Server
Lines: 37
Message-ID: <fn5ne8$eem$1@aioe.org>
References: <479518F6 DOT 7820 DOT CAEFE78 AT gerritvn DOT gpvno DOT co DOT za>, <fn35k9$cjo$1 AT aioe DOT org> <4795BCF7 DOT 26396 DOT F2F9F52 AT gerritvn DOT gpvno DOT co DOT za>
NNTP-Posting-Host: IVw7K97ih4IohxRqyKkqFw.user.aioe.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse AT aioe DOT org
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-Priority: 3
X-MSMail-Priority: Normal
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


"Gerrit van Niekerk" <gerritvn AT gpvno DOT co DOT za> wrote in message
news:4795BCF7 DOT 26396 DOT F2F9F52 AT gerritvn DOT gpvno DOT co DOT za...
> 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?
> >
> 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?
>

Well... uh... not too sure.  If they installed a regular PM ISR, they'd
chain to the end of whatever PM handlers were already installed and be last
in the PM chain and before the original RM ISR.  With _go32_..._iret() and a
PM interrupt, I'm guessing that the _go_32 ISR routine will execute after
all PM ISR's, but before the original RM ISR, just like a regular PM ISR.
But, with _go32_..._iret() and RM interrupt, I'm guessing that the _go_32
ISR will execute before any other ISR's, then PM ISR's, then original RM
ISR.  In both cases, I think it switches to PM and RM twice, but the
execution point of the _go_32 ISR changes: either before or after the PM
chain.  That's my guess at what's happening...


Rod Pemberton