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
