There was a time when even C/370 code and certain LE functions
abended with 0C8, if the fixed point overflow mask bit was enabled;
some LE functions and even compiler generated code tried to clear registers
by arithmetic shift left !!
When calling C/370 functions from PL/1 with FIXEDOVERFLOW or SIZE
condition enabled, we had first to call a ASSEMBLER routine to disable
the 0C8 mask bit. And, sometimes, the passed addresses from PL/1 had
the leftmost bit set, which had to be cleared, before passing the
address to
a C oder LE function ...
Later there was a LE version which captured the 0C8 exceptions and
handled them internally (ignored them). I'm not quite sure if all these
issues
are fixed today, or if still some 0C8 exceptions occur and are handled
by LE
"under the cover".
Kind regards
Bernd
Am 12.02.2012 22:42, schrieb Paul Gilmartin:
What boundaries do you place on Robert's Law? Must the programmer
check for overflow after every fixed point operation, even when
it is known a priori that the operands are such that no overflow
is possible? How about:
SR R2,R2 Clear GR2
BO OVERFLOW_ERROR
??? (There's some argument here for using XR instead of SR for
this purpose if an automated style checker mandates the overflow
test.)
Hardware detection of arithmetic exceptions is a boon here. But
one ISV C compiler requires that the generated code be run with
fixed-point overflow interrupts disabled. Shame on the vendor!
-- gil
