Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.arch
Subject: Re: Wirth's "challenge" (overflows)
Message-ID: <2580@mmintl.UUCP>
Date: Wed, 25-Nov-87 18:23:17 EST
Article-I.D.: mmintl.2580
Posted: Wed Nov 25 18:23:17 1987
Date-Received: Mon, 30-Nov-87 00:39:30 EST
References: <1656@geac.UUCP> <863@winchester.UUCP>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT.
Lines: 20
Keywords: integeroverflow

In article <6777@apple.UUCP> bcase@apple.UUCP (Brian Case) writes:
>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?
>
>We asked ourselves essentially this question during the early days of 29000
>design.  No, there is no "trap on overflow" mode bit.

I think 29000 got it right.

To the person who sometimes enables trapping for debugging purposes:
I would suggest that if you want the traps enabled for debugging, you should
have them on in the finished product -- thus generating add-with-trap
instructions instead of add-without-trap instructions.  Performance is
oft-times a good reason for disabling run-time error-checking, but the same
does not apply to error-trapping.
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108