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