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 P.G.:
>
> 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!
>
> -- G.
>
|