Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!amdahl!nsc!voder!apple!baum
From: baum@apple.UUCP (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: Sticky overflow (was Shift and Subtract is NOT Multiply)
Message-ID: <7486@apple.UUCP>
Date: 7 Mar 88 17:28:57 GMT
References: <7649@pur-ee.UUCP> <7276@sol.ARPA> <718@cresswell.quintus.UUCP>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 17

--------
[]
>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.
>
>Are there any machines which use this approach?
>What are its disadvantages?

The ATT CRISP does this. Both Carry and Overflow are sticky. I don't recall
if there are trap instructions for them, but the are at least special branch
instructions. I also don't know if there is a special reset-overflow inst.,
but branching on overflow will clear the overflow bit.

--
{decwrl,hplabs,ihnp4}!nsc!apple!baum		(408)973-3385