[comp.arch] Why I want an integer overflow mode bit

andrew@frip.gwd.tek.com (Andrew Klossner) (11/25/87)

	"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 doesn't readily compile to your architecture:

	pgm: procedure options(main);

		add: procedure(a, b, c);
			dcl (a, b, c) fixed bin(31);
			c = a+b;
			end;

		declare (a, b, c) fixed bin(31);
		a = 2147483647;
		b = 2147483647;

		on overflow snap begin;
			put list("Overflow, aborting");
			stop;
			end;

		/* This statement should invoke the overflow handler. */
		call add(a,b,c);

		on overflow;	/* Disable overflow exception. */

		/* This statement should not invoke any overflow handler. */
		call add(a,b,c);

		end;

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.

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (andrew%tekecs.tek.com@relay.cs.net)   [ARPA]

bcase@apple.UUCP (Brian Case) (12/01/87)

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