[comp.arch] Why/why-not an integer overflow mode bit

chris@mimsy.UUCP (Chris Torek) (12/02/87)

>In article <9416@tekecs.TEK.COM> andrew@frip.gwd.tek.com
>(Andrew Klossner) writes:

[Does he?  There is something peculiar with the references line above,
and I thought it was someone else...  At any rate:]

>>...in translating a language with dynamic mapping of exceptions to
>>exception handlers ... the same routine ... may need to do both
>>exception-causing arithmetic and exception-free arithmetic depending
>>on the program's history....  Without a mode bit, you have to build
>>a trap handler which does nothing but return, and you take a
>>performance hit.

In article <6871@apple.UUCP> bcase@apple.UUCP (Brian Case) writes:
>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 :-).

I believe that a combination of two things makes the mode bit
unnecessary.  First, intentional overflow is not terribly common,
so the performance hit for a null trap handler would be small.
Second, I suspect that situations under which the same routine must
perform in both excepting and nonexcepting roles are so rare that
even generating two versions of such routines would be inexpensive.
(It may take a fair bit of analysis to determine whether a routine
might possibly be called upon to play both roles, but hey, RISC
machines expect more of compilers anyway :-) .)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris