[comp.arch] Arithmetic Traps in 29000

brian@neptune.AMD.COM (Brian McMinn) (11/19/87)

In article <3440@ames.arpa> lamaster@ames.UUCP (Hugh LaMaster) writes:
>Do the "trap" type instructions interact with a mask in the user context
>which sets which conditions will trap

The Am29000 add/subtract instructions only check for the specific kind
of "wrongness" that is peculiar to that type of add or subtract.  In all
cases, the trap is taken if the answer is "wrong".  For example, the adds
(add signed) operation will trap if the correct result would not fit into
a 32-bit signed integer.  The addu (add unsigned) operation will trap if
the correct result would not fit into an unsigned 32-bit integer.  The
add (add and don't ask dumb questions :-) operation performs no checking.

Using these instructions, the user can specify the proper form of overflow
checking on an operation by operation basis (even finer granularity than
having a user register keep track of whether to trap on Overflow or Carry).

	brian@neptune.amd.com
-- 
	Brian McMinn		brian@neptune.AMD.COM
	Advanced Micro Devices
	Austin, Texas		1-(512)-462-5389

rpw3@amdcad.AMD.COM (rpw3) (11/19/87)

In article <490@neptune.AMD.COM> brian@neptune.AMD.COM (Brian McMinn) writes:
+---------------
| Using these instructions, the user can specify the proper form of overflow
| checking on an operation by operation basis (even finer granularity than
| having a user register keep track of whether to trap on Overflow or Carry).
+---------------

And at the risk of belaboring the point, it only costs 7 instructions of
kernel "trampoline code" to hand a trap back to a user-mode handler.
So the language run-times can do whatever they want with the exception.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403