Paul Gilmartin wrote: <begin snippet> 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! </end snippet>
I agree with this sentiment, but the blame must be shifted to Dennis Ritchie's shade. I know of no serious C/C++ language compiler that supports FIXEDOVERFLOW for binary-fixed. IBM's extension to support packed/decimal-fixed does so. DEC is gone, which I much regret; the architecture of the PDP-7 lives on, which I much regret too. On 2/12/12, Paul Gilmartin <paulgboul...@aim.com> wrote: > On Feb 13, 2012, at 05:16, robin wrote: >> >> The programming world is littered with "it can't happen" cases. >> Everyone knows Murphy's Law ("If anything can go wrong, it will"). >> But not many have heard of Robert's Law? ("Even if it can't go wrong, it >> will".) >> >> So, even it the length were tested prior, one can't assume that all >> will be well when the EX is reached. >> > 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 > -- John Gilmore, Ashland, MA 01721 - USA