0

I'm reading through a computer architecture book and came across the following:

Assume you have a 8-bit cell. So there are 256 possible integer values. Non-negatives run from 0 to 127. Assuming two's complement binary representation, what is the sum of 97 + 45?

Unsigned is clearly 142, you can do it as 97 + 45 in decimal, or:

0110 0001
0010 1101 ADD
--------------
1000 1110

But when you perform two's complement, you take that result (1000 1110) and determine that it is negative since the sign bit is 1. Then take the one's complement of it:

NOT 1000 1110 = 0111 0001

Then determine its two's complement:

0111 0001
0000 0001 ADD
--------------
0111 0010

This number is 114 but because our original number had a 1 in the sign bit, it's -114.

Question(s):

Why go through all the trouble of having the two's complement to find -114? Since 97 and 45, why not just find the sum of the two positive integers as an unsigned value which fits within the range of an 8-bit cell (1111 1111 being 255). Is it just because the question asks for the two's complement?

Is -114 equivalent to 142? I believe so if you take the two's complement number line, yo get 142-256 which is -114. From this, I dont understand why you would want to even use two's complement if you are summing two positive values!

yacc
  • 2,915
  • 4
  • 19
  • 33

1 Answers1

0

A 1's complement just means flip all the bits, a 2's complement means negate the value. So 1's complement for 8-bit results effectively in 255 - x and 2's in 256 - x. You achieve the result of a 2's complement by doing a 1's complement and adding 1.

The 142 in 8-bit is equal to -114. Don't get too confused about it.

yacc
  • 2,915
  • 4
  • 19
  • 33
  • So if I declare `int x = 97; int y = 45; int z = x + y;` I get `142` even though I never declare any as `unsigned`. Does the system determine that what I need is `unsigned` addition? –  Sep 20 '17 at 00:06
  • You also say `142` in 8-bit is equal to `-114` in decimal. But `1000 1110` in 8-but `unsigned` is `142`, `-114` if `signed`. What confuses me is why you would ever want the `signed` version if not using negative values. Sure this is just an example, but you could never return decimal `-114` and say that is the sum of `95 + 45`, it's just wrong...right? –  Sep 20 '17 at 00:09
  • @datta `int` usually represents 32 or 64 bit values. Try it again with `char` if you have a C/C++ compiler handy. Try this: `char x=100; x+= 30; cout << (int)x;` – yacc Sep 20 '17 at 00:11
  • Even still, if I add two positive values, I would think they would never need to be `signed`. Only if I wanted to say add `95 + (-45)` would I need `signed` byte. –  Sep 20 '17 at 00:16
  • This is why most programming languages offer `unsigned` prefix. It's left to the programmer how data values should be interpreted. – yacc Sep 20 '17 at 00:19
  • Perl e.g. doesn't know unsigned. If you had two positive integers and added them, you never could produce a negative result. – yacc Sep 20 '17 at 00:23
  • Humor me if you will. Lets say I do have an 8-bit value (not a typical `int` of 32- or 64-bit). I want to add `97 + 45`. Lets assume its `signed`. Well `142` would put us beyond the range of the 8-bit (ending at `127`) so does it return `-114`? –  Sep 20 '17 at 10:26
  • @datta If it's signed, yes. – yacc Sep 20 '17 at 17:01