Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!umbc3.umbc.edu!umbc4.umbc.edu!brian
From: brian@umbc4.umbc.edu (Brian Cuthie)
Newsgroups: comp.sys.mac.programmer
Subject: Re: 68000 Assembly question -- overflow
Message-ID: <1991May30.161303.1930@umbc3.umbc.edu>
Date: 30 May 91 16:13:03 GMT
References: <12423.284125F3@stjhmc.fidonet.org> <1991May29.210531.7174@midway.uchicago.edu> <1991May30.020707.11193@neon.Stanford.EDU>
Sender: newspost@umbc3.umbc.edu (News  posting account)
Organization: Univ. of Maryland Baltimore County, Academic Computing Services
Lines: 44

In article <1991May30.020707.11193@neon.Stanford.EDU> kaufman@neon.Stanford.EDU (Marc T. Kaufman) writes:
>In article <1991May29.210531.7174@midway.uchicago.edu> tisu@quads.uchicago.edu (Seth Tisue) writes:
>
>>I wasn't advocating one's complement arithmetic -- I'm not that naive.  What
>>I was wondering was, why not have $80000000 (-2^31) be an invalid number
>>rather than -2^31, thus removing the asymmetry?  I'm assuming there's some
>>good reason for this...  What uses does one "often have" for the extra
>>number?
>
>And pray tell, what would you do, special, about this number.  How would you
>set the Flag bits, and how would you modify the CPU arithmetic to deal with
>it?  If the number offends thee, pluck it out.  Program tests in your code
>to deal with it.  It's convenient for most of the rest of us that the +1
>operation works in a consistent manner for ALL bit combinations.
>
>Marc Kaufman (kaufman@Neon.stanford.edu)

Worse yet, is that the interpretation of data is context dependent.  That 
$8000000000 could just as easilly be valid as an unsigned number.  As far
as the processor is concerned, there is no such thing as a positive or
negative number.  The computations are done exactly the same, the flags
are set tha same.  In fact, notice that there are not different instructions
for doing signed addtion and unsigned addition.  The only difference is
in the way that you interpret the results and the flags afterwards.

For representations that are known, such as floating point, it is possible
to have declared illegal values.  For instance, on the VAX an F-Floating type
represents the exponent as an "excess-128" number.  Where 128 becomes a
virtual "0" and positive exponents are added to 128 and negative ones
are subtracted from it.  Obviously, there can be 127 positive exponents
and 128 negative ones.  However, the -128 exponent (or 0) is reserved to
indicate that the number's actual value is zero.  This is necessary becauuse
of the implied ".1" that leads the fractional part of every floating number
on a VAX.  But, these restrictions only apply when using floating point
instructions.  Because they are different instructions, they "know" the
data's type and can impose additional rules.  The integer instructions
have no such luxury (nor do they need it).

Anyway, the moral is: You don't know what the data is explicitly.  It is
completely left to interpretation.  Even floating point numbers can look like
ASCII.  Therefore, there is no good way to cause the processor to
forbid certain numbers from existing as integers.

-brian