[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Exception handling
David Hough 754R work <754r@xxxxxxxxxxx> wrote:
754R alternate exception handling is attached to a "block" which is a
language-defined syntax unit. It would typically be a loop. Having a
synchronization instruction at the end, outside the loop, would not seem
to be a major cost. Since alternate exception handling is usually
enabled staticly (from a language point of view), the compiler knows
just where to place those synchronizations.
Yes, and that isn't a major problem - provided that the hardware makes
a suitable instruction available to unprivileged code. But that is not
always the case.
In some cases, it isn't possible to do that at all, but let's ignore such
seriously broken systems. In others, only privileged code can do that,
so you need a system call (with all the overheads that implies) at each
point - and the overheads of system calls can be dire, not so much
because of the CPU time but because of the effect on the schedulers.
Even when you CAN do it, the cost can be large - as I said, 3-4 times
(according to DEC, and my measurements confirmed that) on the Alpha.
Now, you might fairly say that is unreasonable, but it is also the
case that it is so.
Perhaps the issue is subfunctions invoked within the block with alternate
exception handling attached.
There is definitely a very big issue with this one, but the problem is
caused more by specifications like C99 than by the hardware. Because
C99 allows any function except one in <math.h> and <fenv.h> to generate
false positives, you have to plaster the code with try/catch blocks.
That means that an exception-handling block is a VERY low-level object
indeed, and so the cost is enormous. And there is NOTHING the hardware
can do to solve that :-(
I should have to think about whether there are common constructions
where the specification of IEEE 754R itself requires distinguishing
between 'good' and bad exceptions of the same type. I think that there
are some, but am not sure. And that would cause the same problem.
Otherwise, what are the new issues with 754R throw excepName are that
aren't already faced in dealing with setjmp/longjmp and their ilk?
Somebody has to be prepared to receive a signal (which they were warned
in advance about) that might be generated many layers below (and the
intermediate layers were unaware of the signal generation and
reception). The stack has to be unwound in some kind of orderly way
appropriate to a particular language programming model.
Eh? That's NOT how setjmp/longjmp are implemented! setjmp caches
away some registers, and longjmp reloads them - that's about it. No
operating system intervention, let alone signal handling, is needed.
The same applies to C++ exceptions.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@xxxxxxxxx
Tel.: +44 1223 334761 Fax: +44 1223 334679