Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!ncrlnk!ncr-sd!hp-sdd!trwrc!agnew
From: agnew@trwrc.UUCP (Robert A. Agnew)
Newsgroups: comp.lang.modula2
Subject: -32768
Message-ID: <504@trwrc.UUCP>
Date: 24 Apr 89 18:24:31 GMT
Organization: TRW-MEAD, San Diego, Ca.
Lines: 29


	My comments about -32768 have prompted some rather strange replies.
Please accept my appologies for the hastily posted, poorly phrased,
and not well thought-out posting. Let me replace it with the following 
summary of my thoughts and the replies which I received. 

	There appear to be only two logically consistent alternatives.

1)   Complete the modulo 32768 paridgm by disallowing the value -32768. 
     This would require checking for the value 8000H after every operation
	 and considering it as an overflow condition.

2)   Allow the value 8000H to represent -32768. This would require the
	 ability to discriminate between the two cases:

		 n := -32767 -1;    (* legal -- no overflow *)

	and

		 n := 32767 - 1; n := -n; (* illegal -- produces overflow *)

It appears at first glance that 2) is more trouble to implement than
it's worth. Unless someone can reccommend an efficient and iron-clad
algorithm for 2), I suggest we adopt 1). This was my original recomend-
ation. My original complaint was that the hardware allows -32768
rather than considering it as an overflow. I also was implying that
the original hardware scheme was inconsistent in that respect, but
when I built my first two's-compliment accumulator out of DTL in
1967, the inconsistency wasn't apparent to me either.