1

Say I have 21 - 10 = 10 in decimal.

Signed method:

 10101 - 1010 ----- 1011 = 11 (in decimal)

So far so good,

Now if I decide to use two's complement

 (0) 10101 (21) + 10110 (-10) ----- (1) 01011 = (11)

Here it shows I have a carry in of zero and carry out of one. If I follow the rules of underflow and overflow, this should be considered as an underflow and should not be getting the correct answer in the end.

However, if I decide to add one more bit to work with:

 (1) 010101 (21) + 110110 (-10) ----- (1) 001011 = (11)

In this case, I get the correct answer and no overflow.

I cannot seem to figure out what's happening here and why is it that I'm getting the correct answer for each of these cases in two's complement.

Any clarification would help!

Improve this question
5
  • what is the parenthesized digit on the first line of the 2nd & 3rd snippet? Commented Feb 20, 2015 at 21:07
  • The digits represent the very last "carry ins". See examples: Example Commented Feb 20, 2015 at 21:08
  • So, let me make sure I understand your question: you are wondering how come you get the correct answer in snippet #2 because according to some rules of underflow and overflow (that I am not aware of) snippet #2 should be producing a wrong result? Commented Feb 20, 2015 at 21:11
  • I'm getting the correct answer with a 5-bit representation and a 6-bit representation. According to these set of "rules", if an overflow is produced, the answer should not be correct. In other words, yes. Commented Feb 20, 2015 at 21:16
  • The thing is, no matter how many bits you add, you will always be getting the correct result and carry out. And both of your numbers are representable in 5 bits, so it seems to me that there should be nothing different between 5 and 6 bits. So, not knowing of those rules of underflow and overflow, everything seems fine to me. But, let's see if someone more knowledgeable than me shows up. Commented Feb 20, 2015 at 21:31

2 Answers 2

Reset to default
2

With only 5 bits, 10101 is the representation of -11. You're getting the "right" answer because what you're actually calculating is -11 + -10 and getting 11, which is the incorrect answer, consistent with the rules of over/underflow.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

I think what is screwing me up is the fact that positive 21 doesn't fit in 5 bits since the range is 2^(n-1) - 1
2

In 5 bits, 10101 is not 21!

The most significant bit is set, so it is some negative number!

Improve this answer

6 Comments

Wait, so if the first bit is the sign bit, that means I would need 1 more bit to represent 21? (Snippet 3)
Yes, you would need one more bit to represent 21 and allow for a sign bit at the same time, and of course you do need to allow for a sign bit since what you want to do is add to it a number which is negative.
This explains why the last snippet worked. However, does this mean that both numbers must have the exact amount of bits when handling these types of calculations?
I am not sure how to answer this, since you can extend any number to any number of digits that you like. Keep adding zeros if it is a positive number, or ones if it is negative. So, any number can be made to match the number of bits of another number.
Hmm.. If I take a look at +21 which is 010101, it's represented in 6 bits. However, +10 can be represented using 5 bits, 01010. Taking the two's complement of +10 reveals 10110. Adding both now gives a strange answer.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.