Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!amdahl!nsc!voder!apple!bcase
From: bcase@apple.UUCP (Brian Case)
Newsgroups: comp.arch
Subject: Re: Why I want an integer overflow mode bit
Message-ID: <6871@apple.UUCP>
Date: Tue, 1-Dec-87 13:23:11 EST
Article-I.D.: apple.6871
Posted: Tue Dec  1 13:23:11 1987
Date-Received: Fri, 4-Dec-87 23:15:48 EST
References: <1656@geac.UUCP> <863@winchester.UUCP>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 24

In article <9416@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes:
>
>	"As for the mode bit, we thought about it and discarded it as
>	ugly.  The same effect can be had ..."
>
    [An example of a program that has two invocations of a procedure that
     can cause overflow, but overflow handling is enabled on only one of
     the invocations.]

>The idea is that, in translating a language with dynamic mapping of
>exceptions to exception handlers like PL/I and BASIC, the same routine
>(in this case "add") may need to do both exception-causing arithmetic
>and exception-free arithmetic depending on the program's history (in
>this case, the most recently executed "on overflow" statement.)
>
>Here, the natural way to implement "on overflow;" (the
>turn-off-overflows instruction) is to turn on or off the mode bit.
>Without a mode bit, you have to build a trap handler which does nothing
>but return, and you take a performance hit.

Yeah.  There is a way, though, to do this without the overhead of the null
trap handler:  have the compiler build two versions of the procedure and
invoke the right one.  I didn't say it was pretty, just that it would
work :-).