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
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

- Raw text -