Thread: Exceptions and Interrupts

  1. #1
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195

    Exceptions and Interrupts

    Quote Originally Posted by DavidP View Post
    abachler: you're wrong. Properly written code will generate exceptions. Just not bad exceptions Like I said above: I/O requests, system calls, and page faults (maybe the most common exception of them all) are all hardware exceptions. Of course, there are others which hopefully should not be called by correctly written code, but you never know (integer overflow, floating point error...although these exceptions might be caused purposely by the programmer). Other exceptions we can't control by code at all: hardware malfunction exceptions.
    those aren't exceptions, those are interrupts. huge difference.

    Quote Originally Posted by KIBO View Post
    it doesnt matter really. The discussion started as if boost and Win32 API would rule each other out and they just dont. You cant say, hey I use Win32 so I dont need boost
    hey I use Win32 so I dont need boost.


    Moderator note:
    This thread was split from not enjoying it.
    Last edited by laserlight; 08-21-2009 at 05:43 AM.

  2. #2
    Registered User
    Join Date
    Sep 2001
    Posts
    4,912
    system calls
    Those are exceptions only in the sense that an "exception" is the only way to move from user-land to kernel-mode. So a system call moves parameters on to the stack, and causes an "exception" to actually trigger the shift.

  3. #3
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Not all hardware malfunction is handled by an interrupt and some interrupt handlers may trigger an exception.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #4
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Mario F. View Post
    Not all hardware malfunction is handled by an interrupt and some interrupt handlers may trigger an exception.
    Any hardware error that can be handled by software, firmware, or other hardware is handled through an interrupt. Catastrophic hardware failures are not handled through interrupts for obvious reasons, everything else goes through interrupts.

  5. #5
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    I was under the impression interrupt handler routines would generate exceptions (fault and possibly abort on some cases). This is how I'm thinking the C runtime could relay an hardware failure back to the program exception handler.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #6
    l'Anziano DavidP's Avatar
    Join Date
    Aug 2001
    Location
    Plano, Texas, United States
    Posts
    2,743
    those aren't exceptions, those are interrupts. huge difference.
    Sorry abachler, can't back down on this one.

    Read on:

    Exceptions can be divided into four classes: interrupts, traps, faults, and aborts...

    Interrupts occur asynchronously as a result of signalrs from I/O devices that are external to the processor...Exception handlers for hardware interrupts are often called interrupt handlers...

    Traps are intentional exceptions that occur as a result of executing an instruction. Like interrupt handlers, trap handlers return control to the next instruction. The most important use of traps is to provide a procedure-like interface between user programs and the kernel known as a system call...

    Faults result from error conditions that a handler might be able to correct. When a fault occurs, the processor transfers control to the fault handler. If the handler is able to correct the error condition, it returns control to the faulting instruction, thereby reexecuting it...A classic example of a fault is the page fault exception, which occurs when an instruction references a virtual address whose corresponding physical page is not resident in memory...

    Aborts result from unrecoverable fatal errors - typically hardware errors such as parity errors that occur when DRAM or SRAM bits are corrupted.
    Quote taken from:
    Computer Systems: A Programmer's Perspective
    Authors: Randal E. Bryant and David R. O'Hallaron at Carnegie Melon University
    Pages referenced: 590 - 592
    Chapter title: Ch.8 - Exceptional Control Flow

    Bibliographic Reference:
    R. Bryant and D. O'Hallaron. Computer Systems: A Programmer's Perspective. Prentice Hall, 2003.
    ISBN: 0-13-034074-X

    Interrupts, traps, faults, etc. are all types of exceptions.

    I choose to agree with the smart guys who teach the stuff.
    My Website

    "Circular logic is good because it is."

  7. #7
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Sorry, but Intel doc's trump all 3rd party sources.

  8. #8
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by DavidP View Post
    Interrupts, traps, faults, etc. are all types of exceptions.
    Hmm... in fact I'd say it's perhaps more correct to say the other way around. All exceptions are interrupts. Hardware Interrupts, Software Interrupts and Exceptions (Aborts, Traps and Faults), are a just a convenient nomenclature to help distinguish between the different type of interrupts. But they are all serviced via interrupt vectors. The processor architecture related documentation displays at some point the Interrupt Description Tables which list these vectors. Sorry for not looking for it myself.

    Our beloved breakpoint (a trap exception) is serviced via an interrupt (INT 3), for instance.

    So, I agree making a case on separating interrupts from exceptions is not correct in this context. Unfortunately, you can't really say all interrupts are exceptions because exceptions are a sub-category of interrupts. They are a type of Software Interrupts. But you can argue the other way around saying that Exceptions are in fact nothing else but Interrupts.

    ...

    In any case, I'm bewildered as to why abachler is making an issue of this. And he doesn't seem interested in explaining himself. Instead just fueling more offtrack arguments to hide his initial mistake... and make new ones.

    In the context of the initial discussion this is totally irrelevant. A hardware failure, regardless how it is internally handled by the hardware, the interrupt controller, or the processor, as long as non fatal to the processor normal execution, will almost always result in an exception that can be handled by the programmer. So, KIBO was right in speaking of hardware exceptions, and I immediately understood his meaning. Being picky about it only lead to abachler digging a deeper hole for himself. That, or I'm consistently failing to see his point.

    Quote Originally Posted by abachler View Post
    Sorry, but Intel doc's trump all 3rd party sources.
    And this is the type of arguments that makes me think you are just either having some fun and waste everyone's time, or you really have no idea of what you are talking about. Knowing you, I'd say is the former, since the latter is just not you.

    If we were talking of Intel's architecture, maybe. But we aren't. We are speaking broadly. And even then, the Intel documents contradict you. Of course, you probably guessed you would be safe. Since you just posted them knowing no one would bother reading through all of that to point your mistake.
    Last edited by Mario F.; 08-21-2009 at 06:37 AM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #9

    Join Date
    May 2005
    Posts
    1,042
    I'm pretty sure the definitions DavidP posted are the most correct.

    Sorry, but Intel doc's trump all 3rd party sources.
    This isn't a valid argument.
    I'm not immature, I'm refined in the opposite direction.

  10. #10
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,412
    Quote Originally Posted by BobMcGee123
    This isn't a valid argument.
    How is it invalid?
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  11. #11
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Quote Originally Posted by laserlight View Post
    How is it invalid?
    The argument may be valid, but that doesn't mean it's good. 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.

    Plus, it's not like he quoted anything out of the Intel docs to support his point anyways.

    EDIT:

    Here is the relevant portion from the documentation that abachler posted:
    Exceptions occur when the processor detects an error condition while executing an instruction, such as division by zero. The processor detects a variety of error conditions
    including protection violations, page faults, and internal machine faults. The machine-check architecture of the Pentium 4, Intel Xeon, P6 family, and Pentium processors also permits a machine-check exception to be generated when internal hardware errors and bus errors are detected.
    This was DavidP's claim:
    Like I said above: I/O requests, system calls, and page faults (maybe the most common exception of them all) are all hardware exceptions.
    So even if we use Intel's docs, it only half supports his argument as page faults are still considered exceptions.
    Last edited by bithub; 08-25-2009 at 10:02 AM.
    bit∙hub [bit-huhb] n. A source and destination for information.

  12. #12
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by abachler View Post
    Any hardware error that can be handled by software, firmware, or other hardware is handled through an interrupt. Catastrophic hardware failures are not handled through interrupts for obvious reasons, everything else goes through interrupts.
    There are interrupts, faults, and exceptions. All three are dispatched via the "interrupt vector table" but strictly they are not all interrupts. An interrupt, IMHO, is something which is moderated by an interrupt controller (the APIC chip on the mobo). In contrast something like a divide-by-zero, although dispatched via an interrupt vector, is an exception which is generated interally to the processor, not an interrupt.

    Or to think of it another way, interrupts are asynchronous, while faults and exceptions are synchronous.

    Two cents
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  13. #13
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by BobMcGee123 View Post
    I'm pretty sure the definitions DavidP posted are the most correct.
    The documentation (from intel) is available here: http://www.intel.com/Assets/PDF/manual/253668.pdf (pdf link. You are after Chapter 6)

    Now, while my own argument -- that exceptions are just a different kind of interrupts -- may be open for debate, the authors on the book linked by DavidP are in my opinion grossly mistaken. Exceptions are a subset of the Interrupt Descriptor Table (6.1.0). One can argue they can all be called exceptions. But I disagree. If anything they can all be called an interrupt, since a software forced INT n exception will generate an interrupt (6.4.2). The other exception generation instructions are INT instructions (INT0 and INT 3). The remaining one, BOUND generates INT 5 if the bounds check fails.

    There are clear differences between interrupt and exception handling. So this is why I'm open for debate regarding my own argument on exceptions being a different type of interrupt. But definitely, one cannot say interrupts are exceptions. Exceptions are generated through INT instructions pointing to the interrupt vectors described in the Interrupt Descriptor Table.
    Last edited by Mario F.; 08-25-2009 at 11:09 AM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  14. #14
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    The fact that interrupts, exceptions, and faults are all dispatched via the IVT is simply an implementation detail. They are, semantically, very different things.

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

    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."

    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)

    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. 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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  15. #15
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    Or to think of it another way, interrupts are asynchronous, while faults and exceptions are synchronous.

    Two cents
    To chunk in my 0.2 cents, that is also the way I have always seen the distinction made in Computer Science texts, etc.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. not enjoying it
    By KIBO in forum General Discussions
    Replies: 58
    Last Post: 08-21-2009, 02:41 AM