Article View: comp.lang.modula2
Article #4785-32768
From: Robert A. Agnew
Date: Mon, 24 Apr 1989 18:24
Date: Mon, 24 Apr 1989 18:24
29 lines
1652 bytes
1652 bytes
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.
Technical Details
Message-ID:
<504@trwrc.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!ncrlnk!ncr-sd!hp-sdd!trwrc!agnewShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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