🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.msdos.programmer
Article #3639

Re: Protected Mode Interrupts

#3639
From: Gary A. Hildebrand
Date: Fri, 13 Nov 1992 02:39
40 lines
3116 bytes
In article <4614@cruzio.santa-cruz.ca.us> aki@cruzio.santa-cruz.ca.us writes:
>>I don't see a major problem in sharing interrupt numbers between
>>IRQ chips and exceptions. You layer an exception handler on top
>>of an IRQ handler. The exception handler checks if the PIC is
>>requesting an interrupt. If it is, just call the IRQ handler.
>>Otherwise handle the exception.  Of course the billion dollar
>>question is how to handle an exception that happens simultaneously
>>with an IRQ.  I don't have a billion bucks, thus I don't know.
>>I suggest that everyone just moves the IRQs somewhere else. You
>>can program the PIC with three bytes if you want to. Anybody
>>want to get the data? I would need to dig it out of the manuals
>>again, but it would be no problem.

The problem is that, I would guess 9 out of 10 hardware interrupt handlers
out there don't even check which CPU they are running on, much less
implement an exception handler on top of an IRQ handler.  Most BIOS
implementations also provide nothing special for exceptions in the range of
the hardware IRQ's, and most interrupt handlers contained in drivers or
TSR's would not be able to chain off of the default BIOS handler anyway
(think about it, the ROM BIOS would have to know to transfer control to the
loaded handler, rather than the loaded handler just "stealing" the
interrupt vector).  So, it's a pickle for these interrupts.  You can't just
remap them now, since the whole world is used to doing things the one way.
The onus is on IBM for having made such a terrible design decision to
assign hardware interrupts to a range so close to reserved vectors (8086
doesn't conflict with the range, just 386 or higher).

Having read another post related to this thread, I now realize that one
software interrupt (INT 10H BIOS services) can also conflict with a
reserved 386 or higher exception vector (Coprocessor Error).  But at least
in the case of this, the ROM BIOS of the machine can do (and probably does
do) something to check first for a possible exception.

Gary

--
/ Gary A. Hildebrand                 Internet: gah@mew.mei.co.jp       \
/  Matsushita Electric Works, Ltd.   UUCP:     uunet!mew.mei.co.jp!gah \
/   13-2, Mita 5-chome, Minato-ku    Fax:      03-3451-0793            \
/    Tokyo 108, JAPAN                Tel:      03-3452-4941            \
Technical Details
Message-ID: <GAH.92Nov13113931@HP370T.trc.mew.mei.co.jp>
Path: arc1-ca.pugleaf.net!sparky!uunet!know!mips2!news.bbn.com!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!sun-barr!sh.wide!wnoc-kyo!icspub!oskgate0.mei!chorus.mei!saturn.mew!srl!gah
References: <1992Oct29.075500.15529@cis.ohio-state.edu> <GAH.92Nov9190759@HP370T.trc.mew.mei.co.jp> <4614@cruzio.santa-cruz.ca.us>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!know!mips2!news.bbn.com!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!sun-barr!sh.wide!wnoc-kyo!icspub!oskgate0.mei!chorus.mei!saturn.mew!srl!gah
From: gah@trc.mew.mei.co.jp (Gary A. Hildebrand)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Protected Mode Interrupts
Message-ID: <GAH.92Nov13113931@HP370T.trc.mew.mei.co.jp>
Date: 13 Nov 92 02:39:31 GMT
References: <1992Oct29.075500.15529@cis.ohio-state.edu>
 <GAH.92Nov9190759@HP370T.trc.mew.mei.co.jp>
 <4614@cruzio.santa-cruz.ca.us>
Sender: usenet@srl.mew.mei.co.jp (USENet News Admin)
Organization: Matsushita Electric Works Ltd., Tokyo, Japan.
Lines: 40
In-Reply-To: aki@cruzio.santa-cruz.ca.us's message of 9 Nov 92 18:08:45 GMT