from the we-interrupt-this-story-to-bring-you-another-story dept.
http://www.righto.com/2023/02/8086-interrupt.html
Interrupts have been an important part of computers since the mid-1950s,1 providing a mechanism to interrupt a program's execution. Interrupts allows the computer to handle time-critical tasks such as I/O device operations. In this blog post, I look at the interrupt features in the Intel 8086 (1978) and how they are implemented in silicon, a combination of interesting circuitry and microcode.
[...] The idea behind an interrupt is to stop the current flow of execution, run an interrupt handler to perform a task, and then continue execution where it left off. An interrupt is like a subroutine call in some ways; it pushes the current segment register and program counter on the stack and continues at a new address. However, there are a few important differences. First, the address of the interrupt handler is obtained indirectly, through an interrupt vector table. Interrupts are numbered 0 through 255, and each interrupt has an entry in the vector table that gives the address of the code to handle the interrupt. Second, an interrupt pushes the processor flags to the stack, so they can be restored after the interrupt. Finally, an interrupt clears the interrupt and trap flags, blocking more interrupts while handling the interrupt.
The 8086 provides several types of interrupts, some generated by hardware and some generated by software. For hardware interrupts, the INTR pin on the chip generates a maskable interrupt when activated, while the NMI pin on the chip generates a higher-priority non-maskable interrupt.2 Typically, most interrupts use the INTR pin, signaling things such as a timer, keyboard request, real-time clock, or a disk needing service. The NMI interrupt is designed for things such as parity error or an impending power failure, which are so critical they can't be delayed. The 8086 also has a RESET pin that resets the CPU. Although not technically an interrupt, the RESET action has many features in common with interrupts, so I'll discuss it here.
(Score: 5, Interesting) by coolgopher on Saturday February 25, @03:08AM (1 child)
I know we don't tend to get much discussion under each of these posts, but I'm finding them very enjoyable and informative. Even though I never expect to actually have to make use of this knowledge, it helps build an appreciation for the path that has gotten us to where we are today. And I had no idea about the approach of "jamming an instruction onto the bus" as an interrupt mechanic - I'd never come across that before!
(Score: 2) by janrinok on Saturday February 25, @03:22PM
I agree. Most of my assembly language was done on Z80 but there are similarities between the different sets of code. Nowadays though I prefer to use a much higher level language, but that doesn't mean I am no longer interested in the lower level code too.
(Score: 4, Interesting) by stormwyrm on Saturday February 25, @05:37PM
I got an IBM PC/XT compatible sometime in the latter half of the 1980s after several years with a C-64, and I can still remember some of the details of programming it in assembly language. I remember that there was another chip put in between hardware that could generate interrupts and the 80x86's interrupt pins, the 8259A programmable interrupt controller, which took care of prioritising interrupts and such details as putting in the interrupt vector number on to the x86 data bus when an interrupt was acknowledged. There was an 8080/8085 mode bit in the 8259A's control registers, and it's only from the article itself that I finally learned what that would do: it would jam what amounted to an 8080 CALL instruction onto the bus instead of putting in a vector number. This would obviously crash an x86 though... The article was a pretty fascinating look at how things worked a level or two below the assembly language, to the electronics hardware and then to the silicon inside the chip itself.
Numquam ponenda est pluralitas sine necessitate.