1
\$\begingroup\$

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?

\$\endgroup\$
2
  • \$\begingroup\$ Ignoring the overflow bit is what makes two's complement work. Computers always work in a predefined number of bits. \$\endgroup\$
    – Hearth
    Commented Nov 22, 2018 at 22:48
  • 1
    \$\begingroup\$ Adding two 2’s complement numbers with different signs can never cause an overflow. \$\endgroup\$ Commented Nov 23, 2018 at 2:06

3 Answers 3

3
\$\begingroup\$

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

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

Answer: it could represent +128DECIMAL. The trouble is, the representation would be the same as that of -128DECIMAL. 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:

  • +128DECIMAL is indistinguishable from -128DECIMAL;
  • +129DECIMAL is indistinguishable from -127DECIMAL;
  • +130DECIMAL is indistinguishable from -126DECIMAL;
  • 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 96DECIMAL + 64DECIMAL. The result comes out as -32DECIMAL, which is wrong because the addition register has overflowed.

Note that the example, incidentally, has no carry.

\$\endgroup\$
4
\$\begingroup\$

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.

\$\endgroup\$
3
  • \$\begingroup\$ I will do so noted and thanks. on a side note, I have read that you can get a -0 using 2's complement? how would this happen? \$\endgroup\$
    – fred
    Commented Nov 22, 2018 at 23:03
  • 1
    \$\begingroup\$ Not really, but it's a question of how you interpret the pattern "1000 0000". You could think of this as "-0", but it's also what you get when a result equals -128. The problem is that you can't represent +128 as an 8-bit 2's complement number, so the system is slightly asymmetric in that sense. But in sign-magnitude notation, you definitely can have +0 and -0. \$\endgroup\$
    – Dave Tweed
    Commented Nov 22, 2018 at 23:07
  • 2
    \$\begingroup\$ -0 only exists in one's complement or floating point systems. \$\endgroup\$
    – pjc50
    Commented Nov 22, 2018 at 23:08
1
\$\begingroup\$

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 8th-bit. If we were to incorrectly do the same calculation using more bits, and taking note of the 8th-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 12th 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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.