X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: RM/PM ISR Date: Mon, 21 Jan 2008 17:19:08 -0500 Organization: Aioe.org NNTP Server Lines: 36 Message-ID: References: <479518F6 DOT 7820 DOT CAEFE78 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" 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 Pemberton