Consider the two's complement representation on 3 bits:
3+2 causes overflow.
011+010=100 // why is it 100? I think it should be 101.
And what are the carry in to the most significant bit and carry out from the most significant bit in this case?
the textbook says the carry in to the most significant bit is 1, the carry out from the most significant bit is 0.
I think the text book is wrong. the carry in should be 0 and the carry out should be 1. Am I correct or the textbook is correct?
Please help. Thanks.
Textbook
Right and wrong, I would say, just like so much of life :-)
You're correct in stating that 011 + 010 = 101. The link you posted gave the 100 value of -4 which is a correct interpretation of that value, though not the correct value.
You can generally get the overflowed value by adding the two values without taking overflow into account, then subtracting the range (eight for a three-bit value) if it's more than half the range less one.
In other words, 3 + 2 = 5 but, since this is greater than three (half range less one), you subtract the range 8 to get -3, which is what your correct bit pattern is, 101:
Bit pattern Unsigned Signed
----------- -------- ------
000 0 0
001 1 1
010 2 2
011 3 3
100 4 -4
101 5 -3
110 6 -2
111 7 -1
However, adding the middle bits (with no carry over from the right bits) does actually give you a result of zero and carry of one.
That means the carry into the MSB (left bit) is indeed one. And, when adding those left digits (both zero) with that carry of one, you get one with a carry out of zero.
It may be that you're reading the textbook differently to me but we may have to give it the benefit of the doubt here.
Studying for A level computing we are repeatedly told that a negative normalised floating point binary number is not normalised if it starts with 11 by textbooks, exam questions and teachers.
In the case of minus 11 in twos compliment it can be written as 10101 and so the number in normalised form would be 10101 00100 this follows the rule of no 11 at the beginning of the number
But for minus 1 the twos compliment version is 11111 and so what would the normalised version be, 11111 00100 works but breaks the rule, 011111 00101 makes the number positive and uses too many bits, 10111 00100 makes minus 9 instead of minus 1
Basically why can't the number begin with 11 and how would minus one be represented with an explanation?
You are correct, the normalized version of -1 in binary is 1.100 0001
The problem with this type of maths is that no one really does it. So you're going to find it hard to find any "experts" in this field. The 0.1 and 1.0 rules are useful for learning the concept. However conceptual rules don't always apply in the real world. The point of normalization is to maintain as much accuracy as possible within the boundaries you are given. So if you were to make the exponent 0010 which complies with your rule... 1.010 0010 you are loosing accuracy (not in the case of -1) but the potential is there.
Either there is some confusion with what is written below or my textbook is wrong.
I was looking at examples in my textbook for addition of 8 bit signed binary digits using 2's complement and came across these examples.
We are required to find if any overflow occurs
Example 1]
Adding +75 and -58
+75 = 01001011 ... (a)
+58 = 00111010
-58 = 11000110 ... (b) [took 2's complement of +58]
now adding (a) and (b) we get
01001011
+ 11000110
1]00010001
It was written in textbook that overflow occurs with an arrow pointing to that extra 1 separated with a square bracket.
This example is ok and from here I understood that if there is and extra 1 then we have a overflow.
(Question 1: Am i correct with what i understood ?)
Example 2: This example confused me
Add 53 and (-13)
53 = 00110101
-(13) = 11110011
now adding both we get
00110101 + 11110011 = 1]00101000
And then they wrote: Carry in and carry out for signed bit is 1. So no overflow. Discarding the carry bit and rest is the positive required result
(The main Question: Even though there was this overflow digit(extra 1) why did they say its not overflow. And what are these carry in and carry out for signed bit written in above sentence.)
I did a lot of Google search but couldn't find a good reasonable solution to this line they talked about, or may be it was in front of my eyes but i didn't understand. Somebody please clarify. Most examples I saw(on stack-overflow and other sites) were for 4 bits that confused a bit more. Somebody please help me clarify, Thanks.
Overflow occurs only when correct answer cannot be interpreted using given number of bits.An extra bit is required to interpret the answer right.Consider the following example of byte numbers addition:
+70 in binary 01000110
+80 in binary 01010000
On addition :10010110
1 in the MSB(most significant bit) indicates that answer is negative which is wrong.However if we include an extra 9th bit as a sign bit(=0) we have the answer as 010010110 = 150.The value of this extra sign bit is equal to the carry as a result of addition of bits in MSB(which in this case = 0).
Reference : Computer System Architecture by M.Morris Mano.
I will try to resolve your doubt with the help of examples, where we will ADD two numbers using signed 2's complement method.
But before that let me tell you the condition when Overflow occur.
Basically, overflow occur when carry into the sign bit is not equal to the carry out of the sign bit.
Example Number 1:
Decimal Carry out Sign bit 2’s Complement
-65 - 1 011 1111
-15 - 1 111 0001
---------------------------------------------
-80 1 1 011 0000
1's complement of 0110000 = 1001111
Adding Overflow digit 1 to 1001111 we will get our answer as 1010000.
With signed bit we will get - 1 1010000 which is equal to -80
Carry into the Sign bit = 1
Carry out of the Sign bit = 1
Therefore, No OVERFLOW
Example Number 2:
Decimal Carry out Sign bit 2’s Complement
-65 - 1 011 1111
-75 - 1 011 0101
--------------------------------------------
-140 1 0 111 0100
Carry into the Sign bit = 0
Carry out of the Sign bit = 1
Therefore, OVERFLOW
I hope, that this must have cleared your doubts about Overflow and signed 2's complement Binary Addition technique.
simplest rule while calculating 8 bit number.
Carry-Bit | Sign-Bit
-----------------------------------------------------
0 | 0 --> No Underflow or Overflow
1 | 1 --> No Underflow or Overflow
0 | 1 --> OVerflow
1 | 0 --> Underflow
Add the following using 8 bit signed 2's complement representation:
25 and -40
75 and 80
i want to do the following subtraction using ones complement
Octal(24)-Hex(4B) and give a binary answer
Octal(24) is 20 decimal
and Hex(4B) is 75 in decimal
20->10100
75->1001011
taking 1s complement of 75
0110100 and adding to 20
10100
+0110100
=1001000
adding the carry with the result
001000
+ 1
=001001 which is wrong
Where am i going wrong ?
I am new here, sorry if any mistakes in the way its typed.
You have a small few mistakes in your version. let me show you a correct solution and then show you your mistake(s)
We have the octal number 24 and the hex number 4B. both are fairly easy to translate to binary.
every octal digit represents 3 binary digits.
2 4
+++ +++
010 100
every hexadecimal digit represents 4 digits.
4 B
++++ ++++
0100 1011
now you build the complement:
~01001011
---------
10110100
the you need to add one. Otherwise you get 2 zeros. (+0 => 00000000, -0 => 11111111). this actually makes it a two's complement, but its needed unless you want weird results when crossing the 0-border
10110100
+00000001
---------
10110101
now your complement is done. Next step is to add both numbers
00010100 #The Octal 24
+10110101 #The complement
---------
11001001
The first digit is a 1 therefore its negative (as we'd expect since we did 20 - 75)
Therefore we need to reverse it.
First we subtract one: 11001000
Then we invert it again: 00110111
Which is decimal 55. Therefore 11001001 is decimal -55.
20 - 75 = -55
Voila, we are done :)
First tiny note: you made a small mistake when converting 0x4B (= Hex 4B) into binary format. one digit is wrong :)
Also, you forgot to add one. Then you did some weird stuff i don't get here:
adding the carry with the result 001000 + 1 =001001 which is wrong
Also, you didn't use fixed size numbers which made it impossible to you to find out if the result was negative. I sticked to 8 Bit here (except during octal -> binary conversion). (Keep in mind that with 8 bit your number range is from -127 to +128.) And in the end - as you couln't see its a negative number - you did not revert the process.
I hope this explanation helped you out :)
I'm watching some great lectures from David Malan (here) that is going over binary. He talked about signed/unsigned, 1's compliment, and 2's complement representations. There was an addition done of 4 + (-3) which lined up like this:
0100
1101 (flip 0011 to 1100, then add "1" to the end)
----
0001
But he waved his magical hands and threw away the last carry. I did some wikipedia research bit didn't quite get it, can someone explain to me why that particular carry (in the 8's ->16's columns) was dropped, but he kept the one just prior to it?
Thanks!
The last carry was dropped because it does not fit in the target space. It would be the fifth bit.
If he had carried out the same addition, but with for example 8 bit storage, it would have looked like this:
00000100
11111101
--------
00000001
In this situation we would also be stuck with an "unused" carry.
We have to treat carries this way to make addition with two's compliment work properly, but that's all good, because this is the easiest way of treating carries when you have limited storage. Anyway, we get the correct result, right :)
x86-processors store such an additional carry in the carry flag (CF), which is possible to test with certain instructions.
A carry is not the same as an overflow
In the example you do have a carry out of the MSB. By definition, this carry ends up on the floor. (If there was someplace for it to go, then it would not have been out of the MSB.)
But adding two numbers with different signs cannot overflow. An overflow can only happen when two numbers with the same sign produce a result with a different sign.
If you extend the left-hand side by adding more digit positions, you'll see that the carry rolls over into an infinite number of bit positions towards the left, so you never really get a final carry of 1. So the answer is positive.
...000100
+...111101
----------
....000001
At some point you have to set the number of bits to represent the numbers. He chose 4 bits. Any carry into the 5th bit is lost. But that's OK because he decided to represent the number in just 4 bits.
If he decided to use 5 bits to represent the numbers he would have gotten the same result.
That's the beauty of it... Your result will be the same size as the terms you are adding. So the fifth bit is thrown out
In 2's complement you use the carry bit to signal if there was an overflow in the last operation.
You must look at the LAST two carry bits to see if there was overflow. In your example, the last two carry bits were 11 meaning that there was no overflow.
If the last two carry bits are 11 or 00 then no overflow occurred. If the last two carry bits are 10 or 01 then there was overflow. That is why he sometimes cared about the carry bit and other times he ignored it.
The first row below is the carry row. The left-most bits in this row are used to determine if there was overflow.
1100
0100
1101
----
0001
Looks like you're only using 4 bits, so there is no 16's column.
If you were using more than 4 bits then the -3 representation would be different, and the carry of the math would still be thrown out the end. For example, with 6 bits you'd have:
000100
111101
------
1000001
and since the carry is outside the bit range of your representation it's gone, and you only have 000001
Consider 25 + 15:
5+5 = 10, we keep the 0 and let the 1 go to the tens-column. Then it's 2 + 1 (+ 1) = 4. Hence the result is 40 :)
It's the same thing with binaries. 0 + 1 = 1, 0 + 0 = 0, 1 + 1 = 10 => send the 1 the 8-column, 0 + 1 ( + 1 ) = 10 => send the 1 to the next column - Here's the overflow and why we just throw the 1 away.
This is why 2's complement is so great. It allows you to add / substract just like you do with base-10, because you (ab)use the fact that the sign-bit is the MSB, which will cascade operations all the way to overflows, when nessecary.
Hope I made myself understood. Quite hard to explan this when english is not you native tongue :)
When performing 2's complement addition, the only time that a carry indicates a problem is when there's an overflow condition - that can't happen if the 2 operands have a different sign.
If they have the same sign, then the overflow condition is when the sign bit changes from the 2 operands, ie., there's a carry into the most significant bit.
If I remember my computer architecture learnin' this is often detected at the hardware level by a flag that's set when the carry into the most significant bit is different than the carry out of the most significant bit. Which is not the case in your example (there's a carry into the msb as well as out of the msb).
One simple way to think of it is as "the sign not changing". If the carry into the msb is different than the carry out, then the sign has improperly changed.
The carry was dropped because there wasn't anything that could be done with it. If it's important to the result, it means that the operation overflowed the range of values that could be stored in the result. In assembler, there's usually an instruction that can test for the carry beyond the end of the result, and you can explicitly deal with it there - for example, carrying it into the next higher part of a multiple precision value.
Because you are talking about 4 bit representations. It's unussual compared to an actual machine, but if we were to take for granted that a computer has 4 bits in each byte for a moment, then we have the following properties: a byte wraps at 15 to -15. Anything outside that range cannot be stored. Besides, what would you do with an extra 5th bit beyond the sign bit anyway?
Now, given that, we can see from everyday math that 4 + (-3) = 1, which is exactly what you got.