I know that during the subtraction of two unsigned numbers, let's say a - b, the Carry Flag is set if the result is correct (if a is greater than or equal to b) because when adding the two's complement of b to a an overflow will occur. Now, if b is equal to 0 the result will always be correct, so the Carry Flag should be set, but the addition won't produce an overflow i.e. won't set the Carry Flag because the two's complement of 0 is still 0.
Does the ALU "manually" set the Carry Flag when subtracting 0?
Related
I have been reading a Elements of Programming Interview and am struggling to understand the passage below:
"The algorithm taught in grade-school for decimal multiplication does
not use repeated addition- it uses shift and add to achieve a much
better time complexity. We can do the same with binary numbers- to
multiply x and y we initialize the result to 0 and iterate through the
bits of x, adding (2^k)y to the result if the kth bit of x is 1.
The value (2^k)y can be computed by left-shifting y by k. Since we
cannot use add directly, we must implement it. We can apply the
grade-school algorithm for addition to the binary case, i.e, compute
the sum bit-by-bit and "rippling" the carry along.
As an example, we show how to multiply 13 = (1101) and 9 = (1001)
using the algorithm described above. In the first iteration, since
the LSB of 13 is 1, we set the result to (1001). The second bit of
(1101) is 0, so we move on the third bit. The bit is 1, so we shift
(1001) to the left by 2 to obtain (1001001), which we add to (1001) to
get (101101). The forth and final bit of (1101) is 1, so we shift
(1001) to the left by 3 to obtain (1001000), which we add to (101101)
to get (1110101) = 117.
My Questions are:
What is the overall idea behind this, how is it a "bit-by-bit" addition
where does (2^k)y come from
what does it mean by "left-shifting y by k"
In the example, why do we set result to (1001) just because the LSB of 13 is 1?
The algorithm relies on the way numbers are coded in binary.
Let A be an unsigned number. A is coded by a set of bits an-1an-2...a0 in such a way that A=∑i=0n-1ai×2i
Now, assume you have two numbers A and B coded in binary and you wand to compute A×B
B×A=B×∑i=0n-1ai×2i
=∑i=0n-1B×ai×2i
ai is equal to 0 or 1. If ai=0, the sum will not be modified. If ai=1, we need to add B×ai
So, we can simply deduce the multiplication algorithm
result=0
for i in 0 to n-1
if a[i]=1 // assumes a[i] is the ith bit
result = result + B * 2^i
end
end
What is the overall idea behind this, how is it a "bit-by-bit" addition
It is just an application of the previous method where you process successively every bit of the multiplicator
where does (2^k)y come from
As mentioned above from the way binary numbers are coded. If ith bit is set, then there is a 2i in the decomposition of the number.
what does it mean by "left-shifting y by k"
Left shift means "pushing" the bits leftwards and filling the "holes" with zeroes. Hence if number is 1101 and it is left shifted by three, it becomes 1101000.
This is the way to multiply the number by 2i (just as when "left shifting" by 2 a decimal number and putting zeroes at the right places is the way to multiply by 100=102)
In the example, why do we set result to (1001) just because the LSB of 13 is 1?
Because there is a 1 at right most position, that corresponds to 20. So we left shift by 0 and add it to the result that is initialized to 0.
I have basic binary math question. For example;
reg [31:0] a = 32'hFFFF_FFFF;
reg [31:0] b = 32'hFFFF_FFFF;
reg [31:0] c = 0;
I know c = a - b will result in zero and overflow flag will not be set.
My understanding is that ALU uses 2's complement of subtrahend (right side of operator) and adds it to minuend (left side of operator).
So 2s complement for value stored in reg b is 32'h1. Now, if I add this to reg a, I will get 32 zeros and a 1, which is overflow. Then why is not overflow flag set?
Even if I change width of reg c to 33, c[32] is not set to 1. I understand that when two equal numbers are subtracted, there is no overflow but I get an overflow when I do 2s complement math.
Let help me clear this confusion in my head.
Thank you for your time.
a, b, and c are all 32-bit unsigned variables, and you are performing 32-bit arithmetic. The LRM says the resulting width of an arithmetic operation is the width of its largest operand. So the overflow or 33rd bit is truncated. That fact remains true even when extending c to 33 bits.
you have to look at what two's complement is. So, in your example a and b are 32-bit vectors with all bits set to '1':
a[31:0] = 32'hFFFF_FFFF;
two's complement of this is 32'h0000_0001; so, adding it to b will cause all set to 0 and overflow bit 33 truncated because the width of the operation is 32 bits.
Now, supposedly you have a 33 bit vector
a[32:0] = 33'hFFFF_FFFF;
the two's complement will be 33'h1_OOOO_OOO1. So, if you add it to a 33-bit vector 33'hFFFF_FFFF, you will still have all 33 bits equal to '0'. If you add more bits to a, more 1 be added to the msb side: 34'h3_0000_0001, ...
And, if c is wider than operation context, it will always be 0-extended, for unsigned vars, otherwise sign-extended.
As a result, you will always end up in the situation when the overflow bit is outside of the operation width, and is truncated. This is guaranteed by LRM requirement of the operation width.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
for my computer science class I need to finish a project where I desperately need to understand logic of one´s complement and two´s complement. I already know how to construct these and also how hardware adder works when dealing with two´s complement. The thing that is bothering me and I need help with is the logic behind one´s complement addition. Why do we have to add the bit we would carry over (and discard when using two complement coding) to the sum to get the correct result? I don´t understand why binary addition behaves like this when adding one´s complement and why is that last adding of carry over bit so crucial. I need to understand the logic behind it. Thanks
A 1's complement number (say,16 bits) can be described as below - in terms of the relationship between the binary code c (which is 0..0xFFFF, or 0..65535) and the 'value' x which the code represents, x is in range -32767.. 32767.
if the value x is 0..32767, the code c is numerically equal to x, and thus has a zero in the MSB
if the value x is negative, -1 .. -32767, then c is 65535 - x, and the MSB of c is 1.
The code c=65535 = 0xFFFF is to be interpreted as zero; since it has a 1 in the MSB I will call it '-0'.
Now consider what happens to the x values when you add two codes using a a binary adder:
If both x1, x2 are positive, the adder adds the codes: c = c1 + c2. both MSBs are zero at the input, so there will be no carry. So the value of c will be the sum x1+ x2 and this is how it will be interpreted (assuming the sum doesn't overflow into the MSB).
If both x1, x2 are negative, then by adding c1+c2 you are adding (65535+x1)+(65535+x2). There will always be a carry-out; by discarding this you end up with a binary value equal to 65534+(x1+x2). To get the code we want to represent this negative sum, i.e. 65535+(x1+x2), we need to add 1 more.
If the signs are different, the sum of codes is 65535+(x1+x2). There may or may not be a carry-out. Since the MSBs are different, the carry-out occurs if, and only if, the MSB of the sum is zero. In the case where the true sum (x1+x2) < 0, you won't have a carry-out, and the value 65535+(x1+x2) is the proper code for (x1+x2). If the sum (x1+x2)>0, there will be a carry-out; the sum of the codes (after discarding the carry out) will be (x1+x2)-1, and thus you have to add 1 to get the proper code (x1+x2).
So, looking at all the cases, it works out that whenever a carry-out occurs, (and you effectively subtract 65536 by discarding it) you need to add 1 to get the proper code to represent the sum.
When x1+x2 = 0 -- with one <0 and the other >0 - the sum of codes will always be 65535, which is left as is and is to be interpreted as zero ("-0").
When both are zero, you have three cases:
0 + 0 = 0 Fairly simple...
-0 + -0: codes are 0xFFFF + 0xFFFF = (carry+ 0xFFFE) = 0xFFFF after adding carry back in, interpreted as -0.
-0+ 0: codes are 0xFFFF + 0 = 0xFFFF (-0)
So the only case where the 1's complement sum is a 'proper' 0 is when both inputs are proper 0. All other cases adding up to zero give a '-0'.
Mathematically, you could say that 1's complement uses (c = x) mod 65535, with c constrained to 0...0xFFFF. And so the addition needs to be done modulo 65535. Each time you have a carryout, you subtract 65536 (by discarding it from the top) and add 1 (by adding it at the bottom); since you subtract 65535 in the process, the modulo 65535 value is preserved.
I'm trying to wrap my head around overflow within twos complement for example say I'm trying to take away these two binary numbers:
1111 1000 0100 - 010 111 001 000
I convert the 2nd binary number to it's two complement equivalent and then simply add it but I noticed it resulted in an overflow of 1, do I simply ignore the overflow? or is there a rule I must follow
1111 1000 0100 + 1010 0011 1000 = (1) 1001 1011 1100
Short answer:
if you are performing arithmetic on fixed-width binary numbers, using two's complement representation for negative numbers, then yes, you ignore the one-bit overflow.
Long Answer:
You can consider each ith bit in n-bit two's complement notation have place value 2^i, for 0 <= i < n - 1, with bit n - 1 (the sign bit) having place value -2^(n - 1). That's a negative place value for the sign bit. If you compute the sum of two such numbers as if they were unsigned n-bit binary numbers, these cases are fine:
the sign bit is not set in the either addend or in the result (reinterpreted as being in two's-complement representation),
the sign bit is set in exactly one of the addends, regardless of overflow (which is ignored if it occurs), or
the sign bit is set in both addends (therefore there is an overflow, which is ignored) and in the result.
To understand that, it may be easier to think about the problem as two separate sums: a sum of the sign bits, and a sum of the value (other) bits. An overflow of the value sum yields an overflow bit whose place value is 2^(n-1) -- exactly the inverse of the place value of a sign bit -- therefore such an overflow cancels one sign bit.
The negative + negative case requires such a cancellation for the result to be representable (two sign bits + one value overflow = one sign bit), and the positive + positive case cannot accommodate such a cancellation because there is no sign bit available to be cancelled. In the positive + negative case, there is an overflow of the value-bit sum in exactly those cases where the result is non-negative; you can consider that to cancel the sign bit of the negative addend, wich yields the same result as ignoring the overflow of the overall unsigned sum, and reinterpreting the sum as a two's complement number.
The remaining cases yield mathematical results that cannot be represented in n-bit two's complement format -- either greater than the largest representable number, or less than the smallest. If you ignore overflow then such results can be recognized by an apparent sign flip. What you do with that is a question of error recovery strategy.
From Wikipedia's article on 2's complement in the section on addition at https://en.wikipedia.org/wiki/Two%27s_complement#Addition, my understanding is that carry beyond the given (fixed) bit length (to the left) can be ignored but not overflow as determined when the leftmost two bits of the carry are different. The article shows how to maintain a carry row so as to tell if there was overflow and here is a simple example in the same style:
In 4 bit 2's complement -2 is 1110 and +3 is 0011 so
11110 carry
1110 -2
+0011 +3
----
10001 which is 0001 or simply 1 ignoring the carry in bit 5 and is
safe since the leftmost two bits in the carry row are identical
Although this is a very old question, it comes up frequently. In two's complement addition, a carry out from the leftmost digit is discarded. Why? Although not precisely correct mathematically, it is easiest to think of a two’s complement number as having a sign bit on the left and value bits elsewhere. The only way a carry out of the sign bit can occur is if the sign bits of both addends were one (negative) and there was a carry in to the sign bit. In that case, the sign bit of the result will be one, which is correct. A problem occurs if the carry in to the sign bit is different from the carry out. That causes an incorrect sign bit, which is an overflow condition. That can be detected without referring to the carry out from the sign bit because the sign of the result will be wrong. For example, if two positive numbers are added and the result is negative, something is wrong. The something that’s wrong is that the sum of the value bits has overflowed into the sign bit and the result is in error.
With pen and paper arithmetic, it is usual to discard the carry and check that the sign of the result is correct. In electronic circuits, the easiest way is to compare that carry in to the carry out with an XOR and signal an error if they differ. The carry out is not otherwise used or stored.
I want to substract 1 to the number in binary representation 1010 1101. I write the two s complement of 1: 1111 1111, and I sum with the first number:
bitwise addition, with carry, gives 1 1010 1100: because of carry, I end up with 1 bit more. how is this dealt with in binary addition?
also, I am right in the use of two's complement to do addition?
thanks.
That is an entirely valid and common way to do subtraction, but the 'carry' flag doesn't mean the same thing that it does for normal addition. Since instead of subtracting n, you're adding a large number, the carry flag needs to be handled differently. That extra 1 would usually signify a carry in bitwise addition, whereas here it signifies that everything worked out right. If there wasn't a carry there, it actually means that the result should have been negative - a - b was converted to a + 2^n - b which was less than 2^n, meaning that b > a and so a - b < 0. Either way, it doesn't matter as your result will show up correctly within the 8 bits of your result.