Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: David Thompson <dave.thompson2@verizon.net>
Newsgroups: comp.lang.java.programmer,comp.lang.c
Subject: Re: Arithmetic overflow checking
Date: Sun, 24 Jul 2011 22:13:51 -0400
Organization: Poor
Lines: 36
Message-ID: <32kp27hs1qqcvmdcs9ol4cqg9ge7e4q2u7@4ax.com>
References: <CpmdnZ2c6KsSI4jTnZ2dnUVZ_jydnZ2d@posted.palinacquisition> <wZCdnWNqDO0pe4jTnZ2dnUVZ_v2dnZ2d@earthlink.com> <9LWdnZH2hdfmyYvTnZ2dnUVZ_vidnZ2d@posted.palinacquisition> <pPqdnbD2qr5G7ovTnZ2dnUVZ_qednZ2d@earthlink.com> <3797038f-22d1-40b2-8c12-60db5a0976b8@t5g2000yqj.googlegroups.com> <fn3m17p1p5ipsit6ltmg6rqtlcf5kvdmep@4ax.com> <1d742049-31f6-4eb6-8832-9cce3f25091d@a31g2000vbt.googlegroups.com> <ivg9cp$akq$1@dont-email.me> <08jn17t10eb6qgfdlvriqq8j6e17k5u2ou@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: mx04.eternal-september.org; posting-host="UCUJHv3mRr89vDwj3qlyRQ"; logging-data="28142"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX190YJZXCS0JWqMXYYtPQn9Pyt+e5z3yDUc="
X-Newsreader: Forte Agent 3.3/32.846
Cancel-Lock: sha1:I/XXjRdGk3ABiOGKIbSEcnradp0=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6521 comp.lang.c:8680

On Mon, 11 Jul 2011 21:31:11 -0700, Gene Wirchenko <genew@ocis.net>
wrote:

> On Mon, 11 Jul 2011 21:51:28 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid> wrote:
> 
> >On 7/11/2011 5:54 PM, tm wrote:
> >>[...]
> >> Correct results can be computed without any slowdown,
> >> when the CPU is able to trigger an overflow interupt.
> >>
> >> A slowdown would only happen when an overflow occurs.
> >> Computations without overflow would run at full speed.
> >
> >     Well, no.  At least, not in any trap-capable architecture I've
> >seen.  Three points:
> 
> [snipped nice explanation]
> 
>      How about an example of such an architecture?  A URL would be
> fine.  I believe that /370 had something like that for floating point,
> but not for integer.
> 
S/360 and all successors have masked interrupts for overflows in
'fixed-point' (integer) and decimal (BCD), and unmasked for (original)
floating-point now retronymed 'hex' floating-point. Since IIRC S/390
there is also 'binary' (IEEE) floating-point with its own separate and
more complicated status flags, masks and interrupt causes.

I can't find a usable ref on the IBM site, but if you trust bitsavers:
http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf
page 16 figs 14 and 16, and pp 25 and 33, 35 and 39, 42 and 49.

A few high(er)-performance models of 360, and IIRC 370, did make FP
traps 'imprecise' = not synchronous with the 'right' instruction.