2

The context

I read in a textbook that...

An addition and subtraction cannot cause overflow. To quote,

"An overflow cannot occur after an addition if one number is positive and the other negative, since adding a positive number to a negative number produces a result who magnitude is smaller(...)".

However, by going through some problems it didn't seem to be the case and I want to confirm what I calculated isn't some mistake.

For example a context in which this applies, for a 4-bit adder-subtractor where M=1 (this means subtraction with B), A = 0101 (+5) and B = 1010 (+10).

By taking the 2s complement of B = 0110 (-10) and adding the numbers, the subtraction could be made.

e.g (5)+(-10)

      0 1
+5      0101
-10     0110
-------------
result: 1011
results 2s: 0101 (-5)
C: 0 and V = 1.

A couple of questions already arise just by performing this problem.

  1. The overflow bit is set despite the fact there is no overflow (number is in range)
  2. Given that the range is -8 to 7, wouldn't a signed integer and unsigned integer also cause overflow e.g. (-1+9)

e.g

-1      1110
+9      1001
-------------
result: 1111
result 2s:    0001 (1)

C: 1 and V: 1

I noticed that when C = 0 there is no overflow and when C = 1 there is a overflow.

I read that the overflow relationship between two unsigned integer is the V overflow flag. On the other hand, the overflow relationship between two signed integer is related to the C carry flag. Could this be related?

Finally, notice that there is overflow between an unsigned and signed integer despite the statement I quoted contradicts that.

TL;DR

Is overflow between the addition of an unsigned integer and signed integer possible? If so, what would the relationship an unsigned integer and signed integer be for overflow (C or V flag)?

Community
  • 1
  • 1
Jacky Moon
  • 67
  • 5
  • 3
    10 (or -10) is already problematic in this context, since 4 bit two's complement has a range [-8, +7] – harold Nov 04 '15 at 19:54
  • That's exactly what I was thinking too. Another strange thing is that the calculation works out despite the fact that 10 is out of range. – Jacky Moon Nov 04 '15 at 20:09
  • 1
    addition / subtraction between signed and unsigned integer is not really defined. signed numbers have the sign bit. I think what they meant in that quote is that a positive and a negative number won't produce an overflow. they aren't talking about numbers that aren't the same type. – Catalyst Nov 04 '15 at 20:19
  • See if this answer was cleaner for you https://stackoverflow.com/a/52508879/124486 – Evan Carroll Sep 26 '18 at 01:57

2 Answers2

3

"overflow bit" is usually defined for adding or subtracting two signed numbers, when dealing with signed numbers the first bit is the sign, so for a 4 bit adder 7 is the biggest integer avaliable, when you choose 10 you already choose a number bigger than your adder support, 1010 does not means 10 but -6, you are, in fact, subtracting -6 from 5, wich causes overflow.

EduardoS
  • 199
  • 1
  • 3
2

I think EduardoS's answer is fine, Harold's comment is cleaner. You have 4 bits. That represents

[ -(2**3) , (2**3 - 1) ]

Or, more simply,

[ -8, 7 ]

You pick -10. But, that doesn't exist in that range, so most architectures will wrap it. That wrapping sets the overflow. Let's expand the bitfield to 8 bits.

00001010 = 10

Now we negate it and add one

11110110

Now you can trim off a few of those 1 since it's essentially sign extended but you must store the sign bit,

10110

So you must start out with 5 bits, not 4. Without which you're dropping sign bit and that's overflowing.

Now that that's fixed, what happens if we add

00101 (+5)
10110 (-10)
-----
11011

Now the sign bit is set, so invert and add 1.

11011
00100 (inverted)
00001 (adding 1)
00101 (-5)

So the answer is -5, and you did it without overflowing.

The take away here, is to make a positive number overflow you need to add to it. To make a negative number overflow you have to subtract from it. If both of the numbers have a different sign (and they've valid) they have to fit in in the same space without overflow.

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468