Path: utzoo!mnetor!uunet!husc6!sri-unix!ctnews!pyramid!prls!mips!hansen
From: hansen@mips.COM (Craig Hansen)
Newsgroups: comp.arch
Subject: Re: Sticky overflow (was Shift and Subtract is NOT Multiply)
Message-ID: <1768@mips.mips.COM>
Date: 4 Mar 88 02:27:11 GMT
References: <7649@pur-ee.UUCP> <7276@sol.ARPA> <718@cresswell.quintus.UUCP> <724@cresswell.quintus.UUCP>
Lines: 31

In article <724@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes:
> There seem to be three approaches in current use:
> (1) have an integer overflow interrupt, which is enabled for Pascal
>     and ADA, but disabled for C.
> (2) have a non-sticky overflow bit, which has to be tested after each
>     instruction which the compiler is unable to prove will not overflow.
>     Again, Pascal and ADA would keep testing this flag, C would never test it.
> (3) Ignore the problem and hope it will go away.
>     Very popular for Pascal, normally illegal for ADA.

(4) have instructions that check for and trap on overflow in
    their operation, and have other instructions that don't
    check for overflow. The former kind are used in Pascal
    and ADA code, the latter kind are used in C code.

It's better than #1, because C code and Pascal code can often be mixed
in a single program, and #1 would require some extra code to
enable/disable the interrupt when crossing between C & Pascal code.

#2, adding explicit instructions to check for an overflow, even a
sticky one, isn't a really hot idea, as the overflow doesn't happen
often, (usually no more than once per program invocation), so it's a
shame to waste a cycle each time it doesn't happen. That's what
exceptions/traps are for - to efficiently check for events that are
statistically rare.

-- 
Craig Hansen
Manager, Architecture Development
MIPS Computer Systems, Inc.
...{ames,decwrl,prls}!mips!hansen or hansen@mips.com   408-991-0234