Question: The flag `CF` is set when we compare two digits and one number is less than another:

```
mov eax,1
cmp eax,2
jb truWay

```

In binary form: 

```
1=00000001 
2=00000010=11111101+1(add. code)=11111110и 
00000001+11111110=11111111(no carry)

```

Why does instruction `cmp eax,2` set the `CF` flag? There was no carry, or I'm wrong.

Answer: 
You can refer to [these slides](http://web.cse.ohio-state.edu/~teodorescu.1/download/teaching/cse675.au08/Cse675.02.F.ALUDesign_part1.pdf) to understand how subtraction is performed in an ALU.

While it is true that A - B = A + (-B) and that in two's complement this is A + ¬B + 1, this consideration accounts for the result only. 

A subtracter implemented with half-adders takes the form

              [![A subtracter implemented with half-adders, note the inverted output carry](https://i.stack.imgur.com/0C4Ni.png)](https://i.stack.imgur.com/0C4Ni.png)

Note that the *CarryOut* bit is inverted. 

You can check that this is necessary and correct by taking your example (limiting the size to 4 bits):

1 - 2 = 1 + (-2) = 0001b + 1110b = 0|1111b since ¬0 = 1 we have a borrow

while for 2 - 1 one has

2 - 1 = 2 + (-1) = 0010b + 1111b = 1|0001b since ¬1 = 0 we have no borrow

So in your example, there is a borrow, and thus CF is set, exactly because 0001b + 1110b produces no carry.

For a more formal proof of the correctness of the inverted carry out flag, once can use induction on the number of bits.

*Base case*  

*n = 1*

This can be proven with a truth table

```
a  b   a-b (a+¬b+1)  ¬carryOut  Expected borrow
0  0   0+1+1 = 1|0       0           0
0  1   0+0+1 = 0|1       1           1
1  0   1+1+1 = 1|1       0           0
1  1   1+0+1 = 1|0       0           0

```

*Induction case* 

When subtracting two n-bit numbers A = an an-1 ... a0 and B = bn bn-1 ... b0 we can have A > B, A < B or A = B.  

In the first case there is a *k* such that ak < bk and aj = bj for all *j* > *k* up to *n*.  

The condition ak < bk implies ak = 0 and bk = 1.  

Thus A and ¬B are equal down to the *k-1*-th bit so only this many bits influence the carry out.  

But by the induction hypothesis, the carry out is correct, so it is correct in this case too. 

The same process goes for the case A > B.

The case A = B is easier as the whole operation is reduced to A + ¬A + 1 which reduces to 111...1 + 1 that always produces a carry out and thus no borrow.
**First:**

The result of `a-b` is the same as the result of `a+(-b)`.

However the **flags** set by the operation `a-b` are **NOT** (at least not always) the same flags as the flags set by the operation `a+(-b)`!

This can be seen by comparing different CPU types (e.g. a modern x86 CPU and the historic 6502):

The values of the flags after the operation `a+b` are the same on the x86 and the 6502 while the "carry flag" has exactly the opposite meaning on both CPUs after the operation `a-b`.

This means that the "carry flag" has the same value after the operation `a+(-b)` on both CPUs while the value after `a-b` always differs on both CPUs.

**Second:**

On the x86 the "carry flag" is defined as "borrow out" for subtractions. You could emulate this by

* extending both numbers to a number with more bits - for example 9 instead of 8 bits
* then making the "extended" number negative
* then doing the addition
* ignoring the carry in the addition
* instead using the highest bit of the result as carry

Example:

```
1 = 00000001 (8 bit) = 0 00000001 (9 bit)
2 = 00000010 (8 bit) = 0 00000010 (9 bit)
3 = 00000011 (8 bit) = 0 00000011 (9 bit)
=> -2 = 1 11111110 (9 bit!)

Do the addition:
3 + (-2) = 1000000001 (9 bit plus carry)
1 + (-2) =  111111111 (9 bit)

Ignore carry:
3 + (-2) = 000000001 (9 bit)
1 + (-2) = 111111111 (9 bit)

Use the highest bit as carry:
3 + (-2) =  000000001 = 0 00000001 = (no carry) 00000001
1 + (-2) =  111111111 = 1 11111111 = (carry)    11111111

```