Is HARDWARE exception handling on the horizon ?

[Amn]

Hello all
how you doin' ?

Do you think or heard hardware exception handling mechs are coming our way anytime soon ? At least on x86 arena, which now uses the "ret" instruction for return codes ? And has to proprietarierly implement exception handling which results in somewhat moderate size/speed penalties ?

So any sort of instruction extension coming ? Exceptions are a part of daily life computing now arent they ?

Cya !

[galathaea]

Many processors already have specialized interrupts for hardware exceptions, so are you talking about particular software paradigms and structuring? That would seem to be language and/or OS dependent and might not be processor related. I am unclear as to your proposal, so could you go a little more into what you intend? It sounds quite interesting...

[Amn]

Well i just debugged a throw statement in a program, and i clearly see that no special instructions are involved whatsoever, which leads me to believe it does it the old way. I have a PIII processor. In contrast to a single "ret" instruction this is about 10-12 instructions involved in this....?!....so i thought a hardware implementation would help

Regards,

[galathaea]

I think I see better what you mean . This is a software exception handler (c++) and is therefore language dependent. All of those extra assembly statements you see are to implement the possibility of an unwind (with some other book keeping) through exception segments. This couldn't be implemented in the processor unless the processor enforced a particular calling convention, because stack references, variable methods, etc. vary from language to language. The processor just provides the basic environment in which to execute its set of commands (registers, the concept of a stack, memory addressing, etc.). If an assembly command causes, say, a dbz (divide by zero) it handles that appropriately (processor dependent), and gives the low level exception handling you are asking for. The higher level languages set up the environment in their own way and thus use various and more elaborate schemes to provide for the higher level support of their "exceptions" (which often include things the processor is perfectly happy doing but does not conform to the standard of the language).

Of course, if you are suggesting that there should be processors that set higher restrictions on calling conventions, argument passing, etc. then I totally agree that this could probably make things more efficient. It just might restrict its use from some languages...

Am I understanding you yet? I'm still quite interested if you want to discuss this more!

[Amn]

Yes you got it right

Thats what i hope for...hardware helper instructions dealing with stack unwinding, catch handling etc. Otherwise my framework based on exceptions might grow big and be slower..

There is one thing though about exception speed: there is no speed penalty unless exceptiions are actually thrown

I kind dont like returning errors, because they are easy to miss, and because i use return mech for returning values specific to function like GetName(); etc...the rest, i believe should exceptions do. The fact that they are slower doesnt justify their usage right ? I mean Microsoft uses COM+ in their products anyway, and that thing is even slower, but Office sells

See ya man !