Path: utzoo!mnetor!uunet!ncc!alberta!access!edm!rroot From: rroot@edm.UUCP (uucp) Newsgroups: comp.arch Subject: Re: Is the Intel memory model safe from NO-ONE ?!? Message-ID: <3095@edm.UUCP> Date: 8 May 88 14:43:36 GMT References: <353@cf-cm.UUCP> Organization: Unexsys Systems, Edmonton,AB. Lines: 30 From article <353@cf-cm.UUCP>, by mch@computing-maths.cardiff.ac.uk (Major Kano): > (As an aside, I've heard of 68000 routines doing all kinds of contortions to > check for/avoid overflow because the 68K traps on (eg., zerodivide) and traps > into SUPERVISOR mode (believe it or not). Zerodivide should normally be a USER > (ie., compiler's run time system) problem. With Intel, the user can handle it > without compromising security (conforming code segments). With the 68K you get > NO choice. Any 68K programmers out there who can confirm or deny this ? I Yes, the Divide instruction seems to unconditionially except on a zero divide, but if you REALLY want to ignore zero divide, you can have the interrupt vector point to an RTE instruction (or an OR/RTE pair if you want to set the condition code). The cost on the 68K is about 60 cycles (including both the exception and the return) - somethat less than a full divide. On the '20 the cost is about the same as the cost of a divide. Considering the fact that a zero divide is almost ALWAYS a big boo-boo, I think it is normally more cost effective (in terms of cycles) to blow up on zero-divide than it is to force a program to check for this (should-be) rarity before every division, where a zero divisor is possible. The nice thing is that it gives a programmer the ability to tell the difference between a divide by zero (almost always a mistake) and a REAL overflow (which often gets treated differently) with the possibility of a graceful recovery (above) where you really DON'T care. As far as I can tell, this is the only case where an otherwise innocuous 68K instruction will cause an exception. In any other case, you have to ASK for the interrupt (with a TRAPcc). Although you may not like the trade-off I see it as generally being a plus. -- ------------- Stephen Samuel {ihnp4,ubc-vision,vax135}!alberta!edm!steve or userzxcv@uqv-mts.bitnet