My question here is pretty simple: I want to know if processors try to help exception handling somehow. Would it be possible to completely remove overhead from exception handling and throwing if enough effort is put in designing a processor “exception-ready”?
Because as far as I know, all exception handling is done via software, and that always adds some overhead. Am I wrong?
— edit
So, thanks for all the answers below. I appreciate. You have answered my question.
But just to clarify why I asked this: generally, people don’t go too deep into optimizing exceptions because they all think “exceptions are for exceptional circumstances”, and therefore they are no bottleneck.
I don’t think exceptions should only be thrown under dramatic circumstances. What I think is, basically, that an exception should be thrown anytime a function cannot comply to what it promised to do.
If I say:
doSomethingImportant();
And if for whatever reason “something important” can’t be done, this should throw an exception.
Of course, doSomethingImportant() might not be able to comply because the system ran out of memory (a dramatic problem), but I think we should be able to model simpler “I can’t do that now/this time, sorry” into our software, embedded into our designs. I’d like to say that I think exceptions can be exceptional, yes, but they are to be expected like normal software flow, not as a “fatal error” from which the system has to “recover”, nomsain?
And while big applications backed by nice data centers will hardly ever bottleneck because of exception handling, please don’t forget there’s market for embedded devices where resources are counted, and exception handling does have an impact (which is what I’m aiming for).
I personally find exceptions quite expressive, and I’d like to use them in embedded devices with as much “overhead” as I would get by returning “-1” and checking that with an “if”.
In Instruction Set Architecture documentations, exceptions are abnormal situations for processors (like zero-divide, illegal instructions, etc..). They are usually translated to interrupts (but most interrupts are external signals to the processor).
In programming language specifications, exceptions are non-local control flow constructs, usually involving some kind of call stack unwinding.
I believe that recent micro-architectures handle specially the stack pointer (for instance w.r.t. caching and instruction scheduling). They probably have some circuits dedicated to stack pointers changes required by programming language exceptions.
Some languages and implementations have better exception semantics and machinery than others. For example, Ocaml exception handling is faster than C++ one (at least with the GCC compiler).