2 example additions, why not wear?

I watch David Malanโ€™s wonderful lectures ( here ), which iterates through a binary file. He spoke of signed / unsigned, 1 compliment and 2 additions. The addition 4 + (-3) was added, which lined up like this:

0100 1101 (flip 0011 to 1100, then add "1" to the end) ---- 0001 

But he waved his magic hands and threw away the last burden. I worked a little with some research on Wikipedia, can someone explain to me why this transfer (in 8 โ†’ 16 columns) was dropped, but it retained the one that came before it?

Thanks!

+6
binary twos-complement signed
source share
10 answers

The last migration was deleted because it does not fit into the target space. This will be the fifth bit.

If he performed the same addition, but, for example, with 8-bit storage, it would look like this:

 00000100 11111101 -------- 00000001 

In this situation, we will also stick to the "unused" transfer.

We must consider this method to make the complement with two compliments correct, but all this is good, because it is the easiest way to treat carriers when you have limited storage. In any case, we get the correct result: *


x86 processors store such an extra carry in the carry flag (CF), which can be tested using specific instructions.

+8
source share

If you increase the left side by adding more digit positions, you will see that the transfer is flipped to an infinite number of bits of positions to the left, so you will never get the final transfer 1. Thus, the answer is yes.

  ...000100 +...111101 ---------- ....000001 
+3
source share

Moving does not match overflow

In the example you are running MSB. By definition, this carry-over ends on the floor. (If there was something for this, then it would not be from the MSB.)

But adding two numbers with different signs cannot overflow. Overflow can occur only when two numbers with the same sign produce a result with a different sign.

+2
source share

At some point you should set the number of bits to represent numbers. He chose 4 bits. Any transfer to the 5th bit is lost. But this is normal, because he decided to present the number in just 4 bits.

If he decided to use 5 bits to represent numbers, he would get the same result.

+1
source share

What a beauty of this ... Your result will be the same size as the terms that you add. So the fifth bit is thrown out

In add-on 2, you use the carry bit to signal the overflow of the last operation.

You should look at two LAST bits to see if an overflow has occurred. In your example, the last two bits of the transfer were 11 , which meant there was no overflow.

If the last two bits of carry 11 or 00 , then overflow did not occur. If the last two bits of the transfer have a value of 10 or 01 , then an overflow occurs. That is why he sometimes cared about bit by bit, and in other cases ignored it.

The first line below is the carry line. The leftmost bits on this line are used to determine if there was an overflow.

 1100 0100 1101 ---- 0001 
+1
source share

It looks like you are only using 4 bits, so there are no 16 columns.

If you used more than 4 bits, then the -3 representation would be different, and the transfer of mathematics would still be thrown to the end. For example, with 6 bits you will have:

  000100 111101 ------ 1000001 

and since the transfer is outside the bit range of your view, it is gone, and you only have 000001

+1
source share

Consider 25 + 15:

5 + 5 = 10, we save 0 and let 1 go to a dozen columns. Then this is 2 + 1 (+ 1) = 4. Therefore, the result is 40 :)

This is the same with binaries. 0 + 1 = 1, 0 + 0 = 0, 1 + 1 = 10 => send 1 8-column, 0 + 1 (+ 1) = 10 => send 1 to the next column - this is an overflow and why we just threw 1 .

That is why 2 add-ons are so great. It allows you to add / subtract in the same way as with base-10, because you (ab) use the fact that the sign bit is an MSB, which will cascade operations up to overflow, if necessary.

I hope I understand what I understand. It is rather difficult to explain this when English is not a native language :)

+1
source share

The nose was thrown back because nothing was done to it. If it is important for the result, it means that the operation has overflowed the range of values โ€‹โ€‹that can be stored as a result. Assembler usually has an instruction that can check the transfer beyond the end of the result, and you can directly handle it there, for example, transferring it to the next higher part of the value with several values.

0
source share

Because you are talking about 4-bit representations. This is messy compared to a real machine, but if we took it for granted that the computer has 4 bits in each byte for a moment, then we have the following properties: the byte wraps from 15 to -15. Anything outside this range cannot be saved. Also, what would you do with the extra 5th bit outside the sign bit anyway?

Now, given this, we can see from everyday mathematics that 4 + (-3) = 1 , what exactly did you get.

0
source share

When performing the addition of 2 additions, the only time that the transfer indicates a problem is when there is an overflow condition - this cannot happen if the two operands have a different sign.

If they have the same sign, then the overflow condition occurs when the bit sign changes from two operands, i.e. transferred to the most significant bit.

If I remember that my computer architecture is learning, this is often detected at the hardware level by a flag that is set when the transfer to the most significant bit is different from the most significant bit. This is not the case in your example (there is a transfer in msb, as well as from msb).

One easy way to think about it is like a โ€œsign that doesn't change.โ€ If the transfer in msb is different from the execution, the sign has changed incorrectly.

0
source share

All Articles