Article View: comp.os.msdos.programmer
Article #3639Re: Protected Mode Interrupts
From: Gary A. Hildebrand
Date: Fri, 13 Nov 1992 02:39
Date: Fri, 13 Nov 1992 02:39
40 lines
3116 bytes
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!gahReferences:
<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