Path: utzoo!mnetor!uunet!lll-winken!lll-tis!mordor!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: Sticky overflow (was Shift and Subtract is NOT Multiply)
Message-ID: <734@cresswell.quintus.UUCP>
Date: 5 Mar 88 00:27:28 GMT
References: <7649@pur-ee.UUCP> <7276@sol.ARPA> <718@cresswell.quintus.UUCP> <1755@mips.mips.COM>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 34

In article <1755@mips.mips.COM>, hansen@mips.COM (Craig Hansen) writes:
> In article <718@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes:
> > How about something like this for integer arithmetic?  Suppose there were
> > two flavours of load/move instruction (one to clear the overflow bit, one
> > to leave it alone), and that integer arithmetic instructions were to set
> > the overflow bit, but not clear it.  Then this argument against shift-and-
> > subtract would go away.

> It doesn't work for the multiply-by-seven case, because the
> multiply-by-eight might overflow (and set the overflow bit) even
> though the final result is OK.
> 
Multiply-by-seven was just a lead-in.  What happens if the *PROGRAMMER*
wrote (X*8)-8?  I don't give a ----- about multiplies as such.  I'm
sick and tired of programming languages which completely ignore overflows
in integer arithmetic, and I'm looking for a cheap method which will let
a compiler generate efficient code that *does* check for overflow and
efficient code that *doesn't* without requiring two complete sets of
instructions and without having to continually flip PSW bits.

The original RISC approach had two sets of instructions: with a particular
bit set in an instruction the condition codes are affected, with the bit
in the opposite state the condition codes are not affected.  This lets a
compiler generate checking or non-checking code as appropriate, but still
requires a test after every instruction which might set the codes.
I would like to write a Pascal statement like
	i := (i div 10)*256 + (i mod 10);
which has four operations, and have the overflow test cost at most one
instruction (TRAPV equivalent).

To be perfectly frank, I don't mind too much if the compiler handles
multiplication by a constant in a way that reports overflow a few times
too many.  What I *do* mind, and mind very much, is not being told about
overflow at all.  What good is an "efficient" program that silently
yieds incorrect answers?