When are carry flags set?

What is meant by "Applying a NEG instruction to a non-zero operand always sets the Carry flag.

  Why does substracting 2 from 1 set the carry flag?

            00000001 (1)
  + 11111110 (-2) [in 2-complement form]
  ---------------------
 CF: 1 11111111 (-1) [why is the carry flag set here ???]

+5
source share
4 answers

You can view NEG a as the equivalent of SUB 0, a . If a not equal to zero, then this will set the carry flag (as this will always lead to unsigned overflow).

+4
source
  • First, we know that a < b , a - b can always cause carry ( Borrow ) .

  • Secondly, let's understand why x86 flipped the carry flag when subtracting.
    The first point is so obvious to man, but not for the computer. (Assume that the computer uses a + (~b+1) to replace a - b to perform the calculation.) How does the computer calculate that there is a loan? We can take 2 add-ons as a watch. (Clockwise means the original number - a , counterclockwise means the inverse - ~b+1 )
    enter image description here
    Therefore, for a computer, he can say that (for subtraction), if a > b , a + ~b + 1 will have a transfer (overlay on the image); if a < b , a + ~b + 1 will not have (space in the picture).

  • Output:
    So, for subtraction, if there is no means of transfer, there is borrowing; if there is a transfer medium, do not borrow, that is, invert the transfer bit.

By the way, as far as I tried, there is no overflow (i.e. OF not installed when 1 - 2 ) I do not think @Oliver is right at this point.

+1
source

It is unclear whether the CF flag is read. Intel Docs Guide says:

 If the result of an arithmetic operation is treated as an unsigned integer, the CF flag indicates an out-of-range condition 

The negation of something that is treated as unsigned is clearly invalid, since without a sign value its sign has turned upside down and will still remain unsigned (if it is not equal to zero). Therefore, using the pencil and paper method, you get completely opposite results: "pencil carry = 1" when negating zero and "pencil carry = 0" when negating any other bit diagram.

This is probably why we have the flag carry FLAG 'in the flag register, and NOT' carry BIT '. And again, the carry flag is there to indicate that the result of the operation on the operand (s) (treated as unsigned) is out of the allowable "unsigned range" for a certain number of bits.

If the value you deny is treated as signed, you should see the overflow flag.

The key point here is : "carry FLAG" is not "carry BIT". Sometimes it is bahavas, but not always.

BTW: It's not that only x86 / 64 does this. This is the same, for example, in AVR Atmel.

ARM is likely to do the same, as their manuals state that:

 For a subtraction, including the comparison instruction CMP and the negate instructions NEGS and NGCS, C is set to 0 if the subtraction produced a borrow (that is, an unsigned underflow), and to 1 otherwise. 

and in general, ARM doc call Carry Flag is the Carry / loan flag , so it should not be considered as Carry BIT

+1
source

The carry flag in subtraction is set whenever the result cannot be represented by an unsigned binary number. An unsigned number is always treated as positive.

1 - 2 gives a result that would be -1 , but -1 cannot be represented in the unsigned format of 8 bits, so the transfer flag is set.

This happens even if the substitution algorithm has a result that fits into 8 bits, and even if this result can be interpreted as a binary number with 2 additions with the correct result.

The NEG instruction is intended for use with numbers that will be interpreted as numbers with two additions, because what the instruction does is exactly what is a 2-addition to that number, that is, to change its sign. A sign is a property of numbers with two additions, not unsigned numbers.

NEG n is the same as calculating 0-n , and the only result that works for an 8-bit unsigned number is 00000000 . Another result will not be a valid unsigned number.

0
source

Source: https://habr.com/ru/post/1492602/


All Articles