🚀 go-pugleaf

In article <1990Nov14.210348.27367@Octopus.COM> stever@octopus.UUCP (Steve Resnick ) writes:
>
>With the exception of INT 05, all interrupts < 10H are hardware generated. 
>Int 05 is generated by the int 9 ISR upon make/break of the print screen key.
>Calling hardware interrupts via software is generally not a good idea, since
>the ISR is expecting to diddle the 8259 PIC and maybe other hardware as well.
>
There seems to be some serious confusion here.  There are actually three
types of interrupts:
* CPU-generated interrupts
* Hardware-generated interrupts
* Software-generated interrupts 

Software-generated interrupts are, as we all (should) know, are INT n
instructions.

Hardware-generated interrupts are produced by hardware connected to the
interrupt controller (like the 8259), which in turn yank on the INT line
of the CPU.  By programming the 8259, these interrupts can occur anywhere
in the interrupt range, on 8-byte boundies (even starting at 0).
IBM, in their infinite wisdom chose to 
ignore Intel's warnings not to put hardware-generated interrupts below
20h, and IBM put them (the first 8) starting at 8.  This clearly overlaps
with CPU-generated interrupts on the '286, '386, and '486.  At the end of
a hardware interrupt routine, you must send an End Of Interrupt (EOI) to
the Programmable Interrupt Controller (PIC).

CPU-generated interrupts are, as their name implies, generated by the CPU;
like invalid opcode, or stack fault.  Intel reserved the first 20h interrupts
for CPU-generated interrupts.  Currently (80486), the first 17 (11h) are
used.  The termination of these interrupts don't require writing an EOI
to the PIC.

>Think, also, about what might happen if you call int 0EH (floppy interrupt)
>via software and a hardware floppy interrupt occurs? If the ISR didn't 
>disable interrupts, and the 8259 puts a int 0eH on the bus, you may really
>mung your floppy... 

When a hardware-generated interrupt occurs, upon entrance to the ISR, 
interrupts are disabled.  The ISR doesn't need to disable interrupts, it
is done automatically by the CPU.  This statement is not intended to 
contradict the validity of any of the points I am responding to, I'm
just trying to clarify how this stuff works.

It's true, there is NEVER a valid reason to call a CPU, or hardware-
generated interrupt.  However, for the BIOS, this is a different
story.  Remember on the XT, the coprocessor ERROR was routed through
NMI.  So, IRQ9 (by memory, so don't quote me) must call INT2 to remain
compatibility with programs and hardware that assumes it's running on 
an XT.


-- 
"Worship the Lord your God, and serve him only."  Mat. 4:10
Robert Collins                 UUCP:  ...!sun!altos86!rcollins
HOME:  (408) 225-8002
WORK:  (408) 432-6200 x4356