Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!sdd.hp.com!uakari.primate.wisc.edu!ra!emory!mephisto!mcnc!ramona!andrew From: andrew@ramona.Cary.NC.US (Andrew Ernest) Newsgroups: comp.unix.i386 Subject: Re: Is this (gasp) a chip bug? Summary: 386 is not at fault Message-ID: <1990Jul30.022613.15250@ramona.Cary.NC.US> Date: 30 Jul 90 02:26:13 GMT References: <1990Jul23.223341.26431@cbnewsc.att.com> Distribution: na Lines: 30 In article <1990Jul23.223341.26431@cbnewsc.att.com> imdave@cbnewsc.att.com (david.e.bodenstab) writes: >code bits after 0x80000000 - 0x7fffff01 were VNCZ=1100 (V=overflow, >N=negative, C=carry, Z=zero) >The BGE instruction takes the branch if (Z==1 || N==0). The program >does NOT take the branch when the values of x & y have the above values. First of all, the 386 ref manual says bge takes the jump when SF xor OF == 0 (see page D-2). Secondly, I traced the program by hand and found that SF is always clear (since the result is always 0xff, which doesn't have the 32-bit sign flag set). What happens when y == 0x80000000 and x == 0x7fffff01 is that the OF flag is set. Now SF xor OF == 1 so the branch is not taken and the error message gets printed out. All this *does* make sense (as far as the chip is concerned, that is... I don't know whether or not the C compiler is generating the correct code for "((int) (y - x)) < 0"). 0x7fffffff - 0x7fffff00 is the difference of two positive numbers. Add one to each and you have 0x80000000 - 0x7fffff01 which is the subtraction of a very large positive number from the most negative 32-bit number. Clearly, this is an overflow condition (the result is too negative to represent in 32 bits). And it makes sense that bge doesn't take the jump because 0x80000000 is very negative and is most certainly not greater than or equal to the very positive 0x7fffff01. Note that bge is a signed comparison. The compiler may or may not be broken (depending upon how "((int) (y - x)) < 0" should be interpreted) but the 386 definitely isn't. -- Andrew Ernest