Is this (gasp) a chip bug?

[Michael Davidson]

imdave at cbnewsc.att.com (david.e.bodenstab) writes:

>                                                     The condition
>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.

>I don't understand this.  Admittedly, I'm digging the following up
>from my 20 year old memory of two's compliment arithmetic.

Most 2's complement CPUs do not distinguish between signed and unsigned
values when they perform addition and subtraction - what matters is the
way in which you interpret the condition codes after the operation.

The definition that you give for the BGE (branch if greater than or
equal) is the normal one for a SIGNED conditional branch - ie BGE is
interpreting the condition codes in a manner appropriate for
signed operands. What you need here is an unsigned conditional branch
which on the 386 would be BHS (branch if higher than or same) which
takes the branch if (C==0).

Summary: sounds like your compiler is broken (although I will defer
to more experienced C gurus if they think that your usage of
unsigned variables and (int) type casts was the cause of the
problem - looked OK to me ...)