bartonr@psu-cs.cs.pdx.edu (Robert Barton) (04/15/89)
Consider the following simple program:
(* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *)
MODULE Test;
FROM InOut IMPORT WriteHex, WriteInt, WriteLn;
VAR
int : INTEGER;
BEGIN
int := -32768;
WriteHex(CARDINAL(int), 12);
WriteInt(int, 12); WriteLn
END Test.
(* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *)
With my system (Modula-2/Amiga by TDI) I get the following output:
8000H -4294934528
I believe I have isolated the problem to WriteInt not taking into account
the fact that -(MIN(INTEGER)) # MAX(INTEGER). I recently came across a
similar assembly example that did the same thing, so I'm wondering how
common this bug is. Could anyone with a different M-2 compiler try this out
and let me know the results.ler@lerami.UUCP (Larry Rosenman) (04/16/89)
In article <1007@psueea.UUCP> Robert Barton (bartonr@psu-cs.cs.pdx.edu) says: > Consider the following simple program: > >(* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *) > >MODULE Test; > >FROM InOut IMPORT WriteHex, WriteInt, WriteLn; > >VAR > int : INTEGER; > >BEGIN > int := -32768; > WriteHex(CARDINAL(int), 12); > WriteInt(int, 12); WriteLn >END Test. > >(* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *) > > With my system (Modula-2/Amiga by TDI) I get the following output: > > 8000H -4294934528 > I just tried this on the NEW M2Sprint Compiler from M2S, and got the following results: 8000H -32768 I think the TDI compiler has a few bugs, but it doesn't matter now that the company is gone. Commercial message follows, Hit n if you are not interested. The M2Sprint Compiler is available for $225 (Until May 1, 1989 in the US, and Until May 15, 1989 for International customers. After that it's $385) From M2S, Inc P.O. Box 550279 Dallas, Texas 75355 USA I was one of the beta testers for this package, but also own the other 2 viable compilers (M2Amiga and Benchmark Modula2). The M2Sprint package is unique in that it includes ALL the library sources AT NO ADDITIONAL CHARGE. If you have more questions, feel free to write me. Larry Rosenman (Not affliated with M2S except as a Beta Tester and Therefore customer) -- --- Larry Rosenman ler@lerami.UUCP ..!{texbell,rpp386,pollux}!lerami!ler BIX: ler CIS: 73547,3201 PLINK: LER GEnie: LEROSENMAN ATT: +1 214-401-2705 (Voice) +1 214-401-2706 (Data) USSnail: 1014 San Jacinto #1211, Irving, TX 75063-8244
agnew@trwrc.UUCP (Robert A. Agnew) (04/21/89)
In article <1029@gmdzi.UUCP>, kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes: > That is correct: > int is declared as INTEGER and -32768 is LONGINT. Whether -32768 is or is not a legal number in two's compliment number systems is a topic which could spark a lot of worthless discussion, but I hope not. It seems that each implementor treats it differently. In theory, two's compliment arithmetic is modulo 32768 arithmetic and as such should not be capable of expressing the modulus. The most common implementation of two's compliment arithmetic uses the MSB bit to signify a negative number. The lower 15 bits, the mantissa, are two's complimented. 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). 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. 0x8000 behaves like any other number in most respects and produces correct results. The only bizarre thing about this number is that is it's own two's compliment; i.e. the ones compliment of 0x8000 is 0x7FFF and adding 1 yields 0x8000. Now since -(-0) = -0 does that mean that -0 is not negative to begin with? We note no overflow occurs in this example, but how do we get the value in the first place? I cannot think of any computation that produces 0x8000 without causing an overflow (carry into sign bit # carry out of sign bit) short of getting it from a 16 bit A/D converter where it's usually considered BOGUS. Since, it does not occur naturally in signed arithmetic, why should we admit it? The problem is that most hardware manufacturers specify the range of signed 16 bit numbers to be -32768 to +32767.
kloppen@gmdzi.UUCP (Jelske Kloppenburg) (04/21/89)
I just gave your example to my TDI Modula-2/ST Compiler Version 2.30a.
In the Statement
int := -32768;
it said to that number
this type is not expected.
That is correct:
int is declared as INTEGER and -32768 is LONGINT.
---
Kloppenburg@kmx.gmd.dbp.de
UUCP: kloppen@gmdzi
In real life: Jelske Kloppenburgfirth@sei.cmu.edu (Robert Firth) (04/21/89)
In article <503@trwrc.UUCP> agnew@trwrc.UUCP (Robert A. Agnew) writes: > I cannot think of any computation that produces 0x8000 without >causing an overflow (carry into sign bit # carry out of sign bit) short >of getting it from a 16 bit A/D converter where it's usually considered >BOGUS. Well, how about this computation: -32767 - 1 => -32768 (#8001 - #0001 => #8000) such as would occur, for instance, in i := 0; WHILE i # -32768 DO i := i-1 END; A language or lanugage implementation that arbitrarily excludes one of the legal values of the underlying machine domain is being pretty stupid, especially a systems programming language.
wyle@inf.ethz.ch (Mitchell Wyle) (04/21/89)
In article <1007@psueea.UUCP> bartonr@psu-cs.cs.pdx.edu (Robert Barton) writes: > Consider the following simple program: > With my system (Modula-2/Amiga by TDI) I get the following output: > 8000H -4294934528 antares [tmp]203 cat >t.mod MODULE Test; FROM InOut IMPORT WriteHex, WriteInt, WriteLn; VAR int : INTEGER; BEGIN int := -32768; WriteHex(CARDINAL(int), 12); WriteInt(int, 12); WriteLn END Test. antares [tmp]204 make t m2c -sun3 -o t -e t t.mod antares [tmp]205 ./t FFFF8000 -32768 Looks ok to me. BTW: We run Sun OS 4.0.1 EXPORT Sun Modula-2 Compiler, Release 2.1, key S31.11 -Mitch -- -Mitchell F. Wyle wyle@ethz.uucp Institut fuer Informationssysteme wyle@inf.ethz.ch ETH Zentrum / 8092 Zurich, Switzerland +41 1 256 5237
claudio@amsoft.UUCP (Claudio Nieder) (04/22/89)
I have compiled MODULE t; FROM InOut IMPORT WriteHex, WriteInt, WriteLn; VAR i:INTEGER; BEGIN i:=-32768; WriteHex(i,8); WriteInt(i,7); WriteLn; END t. with M2Amiga V3.2, and the result is: FFFF8000 -32768 -- claudio UUCP: claudio@forty2 BITNET: k538912@CZHRZU1A Claudio Nieder, Kanalweg 1, 8610 Uster, Switzerland