Oppolzer - Informatik / Blog

At least at our site signal handling in C is not allowed. Same goes for user
specified ON units in PL/1 (exception is ON ENDFILE; but even here: why not
check a return code after READ?). Also no volatile definition. All error
handling is centralized. This is IMS dialog, for example. Even third party
software vendors have to follow these rules, or else they are out of business.
But this is very special, I think.

There is a difference, if some language constructs, like volatile, are designed
for very special cases, like embedded devices etc., or they are meant for
general use by normal applications, like it was the case with the original PL/1
condition handling. This is dangerous, in my opinion, and should not be allowed
for free use by application programmers. See C.A.R. Hoare and his famous
historical articles.

Another difference: signal handling in C is part of the standard library and not
part of the language, so the compiler has not to deal with it. Normal arithmetic
does not throw signals in C (overflow and the such are normally ignored, which
is questionable, but it makes powerful optimization possible, because normal
arithmetic is not interrupted by signals).

To Robin: I'm not sure, if REORDER is allowed to move statements, if conditions
may appear at another position by this movement, or maybe disappear. The problem
for optimization in PL/1 is the global effect of the ON units; if specified in
the main procedure, as usual, it covers all the procedures down to the lowest
level and limits optimization everywhere. Think of the effects of an ON SIZE or
ON FIXEDOVERFLOW unit, which can in theory be fired on every assignment and
every expression evaluation.

Kind regards

Bernd



P.G. schrieb:
> Surely this hazard isn't peculiar to PL/I.  Doesn't C's signal
> handling have similar concerns.  C has the "volatile" storage
> attribute to tell the compiler that a storage object may be
> inspected or modified by a concurrent process and that every
> apparent reference in the source must be reflected by an actual
> reference during execution.  This much constrains the compiler's
> freedom to eliminate common subexpressions and move statements.
>
> This was motivated by the need to support microcomputers with
> memory mapped I/O and control registers.
>