I thought that the complement of 00000000 would be 11111111 + 00000001 or 100000000 (256) which leaves 00000000 ?

>>> jim@JPES.COM 04/19/00 04:00PM >>>
 John,

 It seems to me that by subtracting by 2's complement addition,
 when you add 0xFF (Complement of 0x00)+1 to 0x0F (Decimal 15),
 you come up with 0x10F.  Which means, you get a carry because
 you exceeded the byte limit of 255.  In most cases, this carry
 is ignored because it was expected.  That's how I see it
 anyway.


 Now whether this would cause you problems in your application,
 is another story.  Can you just ignore it, or is that not
 feasible in this instance?

 Hope this helps you understand.


                                       Regards,

                                         Jim



On Wed, 19 April 2000, John Albers wrote:

>
> I have looked at several sources for information on using the Carry and Zero flags to compare quantities.  For example, if I use
>
> sublw         L
>
> and the Z flag =1 it can safely be assumed that W=L .  If the Z flag =0, it can safely be assumed that W<>L.  If the Carry flag =0 it can be safely assumed that W>L, and finally if the Carry flag = 1, it can be safely assumed that W <=L .
>
> However, things seem to get weird around 0, assume that W=0, after the following is executed, I think that Carry flag should be zero. (maybe its not, but I would like to know why)
>
> sublw       15
>
> According to the PIC16F84 data sheet, the sublw subtracts by using two complement addition.  Therefore 15-0 = 15 + (Two's Complement of 0) = 15 + (b'11111111' + b'1') = 15 + 0 = 15 which should not set the Carry Flag.  Carry Flag = 0 is supposed to imply that W > L, but W=0 and L=15 , and 0 is NOT greater than 15.
>
> I am still not completely comfortable with two's complement stuff so I could be completely wrong.  Any help would be greatly appreciated.  Thank You.

jim@jpes.com