on 10/11/01 8:24 AM, Ben Larson at wazzapfool@xxxxxxxxx wrote:
> OK I am seriously confused as to the how the compare
> and branch instructions work. Ok first of all,
> correct me if I am wrong, but when you do a BPL
> doesn't that check to see if the value you are
> comparing is greater than the the value in the
> accumulator? Well if that's so, then is the processor
> comparing the two numbers as unsigned 8-bit integers
> or signed? In other words, what would be the outcome
> of, say...this:
>
> LDA #100
> CMP #-20 ; -20 signed = 236 unsigned
> BPL AIsLess ; in a 2's comp. representation
> AIsNotLess
> .
> .
Actually, the BPL instruction tests if the result is POSITIVE (I.E. BIT #7
is clear). Many people think it means a signed branch if greater, however
there are cases it doesn't work.
Now the unsigned compare works flawlessly with BCC (BLT) or BCS (BGE) in
which you do the compare on two UNSIGNED values and the branch is properly
chosen.
The problem with the signed form is overflow. Such like
LDA #127
CMP #-128
BPL Foo
In SHOULD be branch taken, however, hex 0x7f subtract hex 0x80 = 0xFF A
NEGATIVE number. The proper code for a signed compare is...
LDA #127
SEC
SBC #-128
BVC Ok
EOR #128
Ok: BPL Foo
Here the OVERFLOW flag detected that the sign got screwed up in the
subtraction, so the EOR #128 reversed the sign and hence reversed the
branch.
The BPL now reflects a signed entry
Burger
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
