Jtdylktuy

So lets say I used 2's complement to put -17 in binary and then I added it to +27, e.g.:

  +27    0001 1011b

+ -17    1110 1111b

-------------------

  +10    0000 1010b

This calculation here should have an overflow of 1. Where did this overflow of 1 go? How can you possibly just disregard it when it would completely change the whole calculation?

When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?

Also, does 2's complement have -0 value and a +0 or only one 0 value?

Carry and overflow are not the same thing.

The MSB of a 2's-complement number is the sign bit. The bit you're talking about is the carry-out from the addition of the MSBs. There is an "overflow" only if the signs of the operands are identical AND the sign bit of the result and that carry-out are not identical. If the signs of the operands are different, then there cannot be an overflow, regardless of the state of the carry-out

Try a few examples for yourself to see how it works.

There are many ways to explain it. Here is one.

Eight-bit signed binary can represent integers as low as -128_DECIMAL and as high as +127_DECIMAL. So, why can it not represent the next greater integer, +128_DECIMAL?

Answer: it could represent +128_DECIMAL. The trouble is, the representation would be the same as that of -128_DECIMAL. See:

DECIMAL   BINARY

-128      1000 0000

-127      1000 0001

-126      1000 0010

...

+126      0111 1110

+127      0111 1111

+128      1000 0000

+129      1000 0001

+130      1000 0010

...

Observe:

• +128_DECIMAL is indistinguishable from -128_DECIMAL;


• +129_DECIMAL is indistinguishable from -127_DECIMAL;


• +130_DECIMAL is indistinguishable from -126_DECIMAL;


• and so on.

By keeping the carry bit (it's actually not an overflow bit; overflow is something else), you would be affirming the false representation, wouldn't you? Try it. You'll see.

You don't want that carry bit.

NOTES ON OVERFLOW

If you wish to know what overflow is, it's what happens when you try (for example) to add 96_DECIMAL + 64_DECIMAL. The result comes out as -32_DECIMAL, which is wrong because the addition register has overflowed.

Note that the example, incidentally, has no carry.

Picking up this specific bit:

When you add 2's complement numbers, does it just always mean you have to work in a predefined number of bits, and if so, why?

Yes, you need to know the number of bits you are going to be working with, because that determines what the two's-complement representation of your negative number will look like.

So, in your example, you have:

  +27    0001 1011b

+ -17    1110 1111b

-------------------

  +10    0000 1010b

where there would be a "carry" out of the 8^th-bit. If we were to incorrectly do the same calculation using more bits, and taking note of the 8^th-bit carry, we would get the wrong answer:

  +27    0000 0001 1011b

+ -17    0000 1110 1111b     << WRONG representation of "-17" in 12 bits.

------------------------

 +266    0001 0000 1010b     << WRONG answer in 12 bits.

However, if we do this again, but using the correct 12-bit representation of -17, then we again get the correct result, although here we are "ignoring" the carry out of the 12^th bit:

  +27    0000 0001 1011b

+ -17    1111 1110 1111b     << Correct representation of "-17" in 12 bits.

------------------------

 + 10    0000 0000 1010b     << Correct answer in 12 bits.

Conceptually, you can think of the "true" two's-complement representation of -17 as being an infinite string of 1s, ending in ...10 1111. When doing calculations with a finite number of bits, you take just enough of those 1s to fill your register and discard any "carry" that would go outside that size.