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 :-).