[comp.lang.modula2] Two's complement and -32768

bartonr@psu-cs.cs.pdx.edu (Amiga 1000) (04/23/89)

From: agnew@trwrc.UUCP (Robert A. Agnew)
> Theoretically, that means -n (0 <= n <= 32767) is represented by 32768 - n
>which are congruent modulo 32768. This operation is accomplished in hardware
>by taking the one's compliment ( logical NOT) and adding 1. This works because
>the logical compliment of n is 32767 - n (try it).

  I think this depends on what hardware you're talking about.  For example, the
Motorola M68000 series processors define -n as 0 - n.  So for example,

                 0000  (* 0 *)
                -8000  (* subtract -32768 *)
                -----
                 8000  (* result = -32768 *)

> The problem arrises because the value 0x8000 can and does occur. The
>hardware interprets this number as -0, a value which is regarded by many
>to be as unclean and wierd as the square root of minus one; many systems
>thus treat it as an "illegal" number. Other systems choose to interpret it
>as -32768 since 32768 is congruent to 0 modulo 32768.

  Treating it as -0 sounds like sign-magnitude notation, not two's-complement.

> note no overflow occurs in this example, but how do we get the value in
> the first place?

  The 68000 does generate an overflow in this case.  Specifically, if the MSB
of the original number and the MSB of the result are both 1, then the negation
produced an overflow.  Note that this can only occur in one case - if the
original number was 8000 hex.

> The problem is that most hardware manufacturers specify the range of signed
>16 bit numbers to be -32768 to +32767.

  I don't see where this is a problem; you just have to recognize it as a
special case and treat it as one.  After all, we don't get rid of zero just
because we can't use it as a divisor.