| glen herrmannsfeldt 2007-11-28, 7:12 pm |
| (snip on exception handling, such as fixed point overflow)
(someone wrote)
(Craig Dedo wrote)
[color=darkred]
That sounds a little similar to PL/I ON units.
Many exceptions ( FIXEDOVERFLOW, OVERFLOW, UNDERFLOW, SUBSCRIPTRANGE,
ZERODIVIDE, SIZE, STRINGRANGE) for example) can be enabled or disabled
by block or by statement.
Ones that require extra code to detect will generate that code only
when enabled. Some default to enabled some disabled.
http://publibz.boulder.ibm.com/cgi-...S/ibm3lr30/16.1
(snip on ENABLE blocks)
[color=darkred]
> There were a couple of problems that I can remember. Many large
> scale programs are essentially memory limited (thrashing to disk
> isn't a viable option for production problems). How do you track
> access to an undefined variable?
(snip)
Undefined variables are a problem, but not considered a reportable
exception in most cases. Fixed point overflow detection has been in
question for a long time. Some hardware can detect it easily,
other hardware can't.
> A specific problem with the ENABLE block was what to do with an
> untrapped exception down the call tree. Given something like
> SUBROUTINE A
> ENABLE SOME EXCEPTION
> CALL B
> ...
> END
(snip)
> What should happen when C throws the exception? Should the program
> die because C has no exception handler? Or should it pass control
> back up to A where there is a handler? Both are justifiable ideas.
PL/I passes control to A, but I agree, all are reasonable ideas.
> If you want to pass control back up the tree then B has to do the right
> thing when C returns and unwind the stack, store local variables,
> deallocate things, etc. But, if B is separately compiled it has no idea
> that exception processing is going on. So, every call will have to
> have handling code to look at a status return and, effectively, we'll
> require that every existing library be recompiled with the new calling
> sequence. In the good old days, when "we're the Fortran team, that's
> why" would settle an argument, this was less of a problem.
In PL/I an ON unit is its own block. In many cases when the ON
unit is done control returns to the original point. It may also
do a non-local GOTO, which will unwind the stack. I don't know
that it requires a different calling sequence, or just the ability
to follow the stack back to the appropriate point.
(snip)
> What should the effect of inlining be? Should well checked,
> well debugged inlined code be compiled with the same through
> error trapping as the host?
> There were two schools of thought on when an exception should trap.
> Should it be precise, enabling a careful programmer to fix things
> up and continue on. Or, should it be imprecise and just give a general
> indication of where things went bad? Precise interrupts kill
> optimization. On modern machines letting pipelines become quite so
> that interrupts can propagate is a factor of 10 or more in performance.
This problem goes back at least to the 360/91 (for PL/I).
(snip)
[color=darkred]
Some people value right answers, which I believe is what started
this thread. If one can enable or disable the checks as appropriate
the cost might not be too high.
-- glen
|