Thread: Exceptions and Interrupts

Originally Posted by brewbuck

The fact that interrupts, exceptions, and faults are all dispatched via the IVT is simply an implementation detail. They are, semantically, very different things.

That is not my understanding. They are indeed semantically different. But not very. We see both being discussed together and in function of one another. Even on detailed documentation. This isn't just a coincidence or implementation detail.

Let's see...

An interrupt is an asynchronous notification by a piece of hardware.

Except if they are software generated interrupts (6.3.3). But see below...

Exceptions and faults are both synchronous events which differ in their interpretation. A fault indicates a recoverable error, and thus after the system is done processing the fault, control returns to the same instruction which generated the fault. This is how paging works, for instance. You attempt to access a page which isn't mapped, so a page fault is generated, the OS swaps the page in, and control returns back to the same instruction again for a "retry."

You are talking of faults. A fault is an exception type. (you may want to edit the first phrase).
Indeed faults return from the handling mechanism is different from interrupts. And yet...

An exception indicates a non-recoverable error, such as a divide-by-zero -- a problem which cannot be solved. Thus, control returns to the instruction after the one which generated the exception (if it returns at all -- most operating systems will just kill the offending process since it makes no sense to continue)

Here you are talking of Traps (sorta..."control return to the next instruction" is a trap behavior. Divide by zero is instead a Fault so control returns to the same instruction since the exception occurs before the instruction is executed). Traps return from the exception handler is similar to interrupts.

Intel CPUs have an instruction called "INT" which generates a "software interrupt" which is a very, very poor name for it. It is not an interrupt -- interrupts are asynchronous while a call to INT is synchronous.

This is indeed the problem. Where the distinction is made less clear. But I strongly disagree with your opinion. It exists nowehere in any literature I have ever read. And it really doesn't help if you chose to ignore the vendor specifications and terminology, just for argument sake.

For all purposes, software interrupts are interrupts. With the sole exception of the NMI vector, the processor processes software interrupts in basically the same way it processes hardwareinterrupts.

What INT does is invoke a handler via the IVT. That's all it is -- a transfer of control to a given block of code. It is no more an "interrupt" than a JMP instruction is an interrupt.

And what does a hardware interrupt do that is significantly different? The APIC or the INTR pin being asserted will force an implicit call to the interrupt handler. The INT instruction bypasses nothing.

...

Exceptions and Interrupts intersect in many areas. Definitely this makes it possible to distinguish between both. But it is undeniable that they share many common features and official documentation is clear in describing both in the same context.

I agree we can spot the differences. But so we can between different kinds of actual Interrupts like hardware interrupts, software interrupts, the non-maskable interrupt, and the not mentioned yet processor interrupts (INIT#, SMI#). Interrupts and Exceptions fall in the same bag as similar constructs with their differences.

Sorry, but Intel doc's trump all 3rd party sources.

I answer that just by requoting what bithub already stated:

Interrupt and Exception are computing terms that existed long before Intel. So saying that Intel's docs are the de facto authority on the matter seems odd to say the least.

There is a world of processors out there, and Intel has never been the de facto authority on terminology.

Intel CPUs have an instruction called "INT" which generates a "software interrupt" which is a very, very poor name for it.

Thankyou, brewbuck, for bringing up this point. You are completely 100% correct in this, and this is something that most programmers don't understand. Although we disagree on whether interrupts are included in the definition of an exception or not, what you stated here is definitely very important.

In fact, I think the INT instruction is one of the primary reasons why there is so much confusion as to what an interrupt really is. Like brewbuck already stated, "An interrupt is an asynchronous notification by a piece of hardware". An interrupt never has been, and never will be, a subroutine called by a programmer.

As I first tried to learn about processors and assembly language before college, I learned that an interrupt was something that I called by calling the "INT" routine in my code. Boy was I wrong. When I went to college and started hearing about "traps", I thought to myself, "Why are they calling those things traps? They are interrupts!" Unfortunately, I had learned wrong, and I think that is the case with most programmers.

An interrupt is an asynchronous signal by hardware directed towards the processor. An example is the keyboard telling the processor, "Hey, I have another key for you to process!" The processor then handles the interrupt by calling an interrupt handler found in memory...mind you this interrupt handler is taken care of silently by the processor and your code you wrote was never even glanced at in this process.

A trap is a more correct description for the INT subroutine on intel processors. A trap is a subroutine called by a user, but it is normally a system call...not just any ol' subroutine call.

Hence, I hope this clarifies the difference between an interrupt and a trap, and I hope people aren't too hurt when they learn that the INT instruction doesn't actually call an interrupt.

Now, as to the definition of exception vs interrupt. Although I know wikipedia is not the most credible source, I will use it briefly here:

Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution.

The interrupt by hardware directed towards the processor causes an interrupt handler to be called by the processor, hence it changes the normal flow of program execution - user code gets put on hold while the processor goes and executes some special code of its own, and then when its done it returns control to user code.

I think this qualifies as "Exceptional Control Flow" (to quote the chapter title of the textbook I quoted previously), and hence I completely consider an interrupt to be considered a type of exception.

Originally Posted by DavidP

"An interrupt is an asynchronous notification by a piece of hardware". An interrupt never has been, and never will be, a subroutine called by a programmer.

Can you support this claim, or is this just how you feel about it?

Hence, I hope this clarifies the difference between an interrupt and a trap, and I hope people aren't too hurt when they learn that the INT instruction doesn't actually call an interrupt.

Nothing calls an interrupt. An interrupt is not a callable piece of code. There's only interrupt descriptors and interrupt handlers served by a task, trap or interrupt gate addressed by in the IVT. An INT instruction follows the exact same path, no less. The difference is that a software interrupt cannot be masked (but then you also have non-maskeable interrupts too, the NMI) and operates synchronously.

The problem you mention of programmers not being able to make the distinction is instead the fact they fail to see the difference between a software interrupt and a hardware interrupt -- a mistake you are committing now -- not between an interrupt and a exception.