Is this (gasp) a chip bug?

[Andrew Ernest]

In article <1990Jul23.223341.26431 at cbnewsc.att.com> imdave at 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 <andrew at ramona.Cary.NC.US>