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...
Except if they are software generated interrupts (6.3.3). But see below...An interrupt is an asynchronous notification by a piece of hardware.
You are talking of faults. A fault is an exception type. (you may want to edit the first phrase).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."
Indeed faults return from the handling mechanism is different from interrupts. And yet...
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.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)
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.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.
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.
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.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.
...
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.