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