Hexadecimal in mips: If I have 0x80000000 and I subtract it by 0xD00000000
my answer is 0X -50000000
is this possible in mips having a negative in or is there another way to write this? That is correct?
Remember, if you look at the most significant bit, you'll know if you are working with a negative number. For simplicity, let's just look at the four most significant bits.
0x80 = 1000 0000
0xD0 = 1101 0000
So those values are already negative. You want to subtract them, that is, 0x80 - 0xD0. Well, subtraction is addition (a-b = a + -b), and the whole point of 2's compliment is that you can add signed numbers and get the result you expect. So let's negate 0xD0:
1101 0000 # original value
0010 1111 # flip the bits
0011 0000 # add 1
If that didn't make sense, ask the all-knowing Wikipedia.
Now, we can add the values:
1000 0000
0011 0000
---------
1011 0000
So if I've done it right, 0x80 - 0xD0 = 0xB0. It's still a negative number (but you don't put a minus sign in front of it, it's implied by the MSBit). And that makes sense, because 0x80 is a very negative number, and 0xD0 is a less negative number than 0x80. (Really, it is... 0xFF is -1, the least negative number.)
Related
I'm having trouble converting the following two’s complement binary number to decimal
01110000
Step 1: Invert the bits -> 10001111
Step 2: Add 1 to the bit -> 10010000
Therefore, the decimal value is 144
However, I used online converter and it says the decimal value is 112
The value of ...111 0111 0000 (padded with an infinite number of 1's) is -144. The value of ...000 0111 0000 (padded with an infinite number of 0's) is 112. Given the former, one could compute its additive inverse by inverting all the bits (yielding ...000 1000 1111) and adding 1 (yielding ...000 1001 0000, i.e. 144).
If I have
0010 1101
0110 1111
____+
1001 1100
Is it overflow? because the sign of the first digit becomes 1 and 1 represents negative? I am very weak in binary.
What if you add
1111 1111
1111 1111
___+
1111 1110
with carryout 1 that is not an overflow? because 1111 1110 represents -2?
Thanks for helping!
It depends on how you are treating your value - is it signed or unsigned. If it is unsigned binary, than it is not overflow. If it is signed one, than overflow did occure.
I guess we are talking about signed values, than basicly, overflow is when value change its sign due to binary arithmetic operation which result exceeds max-min range.
If you are using a plain binary representation without sign, it is not an overflow
0010 1101->45
0110 1111->111
45+111 = 156. You can operate in the range [0, 255] then it is not an overflow.
If you are using the two's complement you have the range from -128 to 127, having only one representation of 0. Then it is an overflow because 156 is out of the range [-128, 127]
You can not just use the first bit to represent the sign because then you have 10000000 and 00000000 representing 0 and -0. The you should use two's complement to operate with negative numbers.
From the book, Art of Assembly, I copy this quote:
In the two’s complement system, the H.O. bit of a number is a sign bit. If the H.O. bit is zero, the number is positive; if the H.O. bit is one, the number is negative. Examples:
For 16-bit numbers:
8000h is negative because the H.O. bit is one.
100h is positive because the H.O. bit is zero.
7FFFh is positive.
0FFFFh is negative.
0FFFh is positive.
I don't understand the last two examples. If you convert the two examples to binary, you get 0000 1111 1111 1111 1111 for the first and 0000 1111 1111 1111 for the second. Why is the former negative and the latter positive? It seems to me that the highest order bit for both would be 0 and therefor both should be positive.
The reason for the leading 0 on 0FFFFH is to give the
assember/compiler a hint that F is part of a number. Not all
assemblers require this.
So the negative number is in reality FFFFh, so 1111 1111 1111 1111, then is negative.
computer-programming-forum.com/46-asm/1b99282efbac3bcf.htm
The text says: 16-bit numbers. So you need to look at the 16th bit from the right. In 0FFFF, that would be a 1. As for the leading zero, it's notational hint that the value is a number, not a word (i. e. not a variable).
Parsers (including assemblers) have easier time parsing numeric literals if you establish a convention that a valid number can only start with a digit. So do some humans. DEADBEEF is a valid hex number, y'know.
could you explain why 0FFFF has 5 digits? Is it the same as FFFF
It is not the same. Just plain FFFFh will be interpreted as a symbol by the assembler. And you'll get a compile error since it cannot find any symbol named "FFFFh". Putting a 0 in front of it ensures that the assembler will interpret it as a number.
if the number should be 16 bits, the 16th bit is taken as the sign bit. in the first,
0FFFFh
the 16th bit is 1 as it is
0000 1111 1111 1111 1111
in the second example,
0FFFh
the 16th bit is 0 as it is
0000 1111 1111 1111
the 16th bit is 0, though there are more than 16 digits, binary considers only the first 16 digits. so, the first is negative and the second is positive
I'm not sure if I can ask a binary question here but here goes..
We had this question on our midterm but our professor hasn't provided a correct answer for it. It's been driving me crazy and the final is coming soon so it might be a good idea to fill this gap. Thanks!
Find the smallest two's complement number that, when added to 0101 0101 would result in an overflow. Express your answer in binary.
My reasoning:
I found the range of the original binary 0101 0101 by converting it to an actual number and then added one to it. Then I converted the number that was 1 more than the range into 8-bit binary as my answer. However, this only earned me 3/6 marks. I have no idea what else I could've done. Any insights would be greatly appreciated!
The original binary is a positive number (0 sign bit). Overflow occurs when you add a positive number to it that changes the sign bit. It should be easy to see what the smallest number is using binary notation:
No overflow:
0101 0101
+ 0010 1010
---------
0111 1111
Overflow:
0101 0101
+ 0010 1011
---------
1000 0000
I have no idea if this is what your prof was looking for. (You can probably just subtract from 1000 0000 instead of looking at it as a pattern.)
EDIT Since you asked for an example (meaning something different from the above), here's how subtraction would work:
1000 0000 (the target overflow quantity)
- 0101 0101 (the original binary)
---------
0010 1011 (the smallest number that will overflow when added to original)
That number is 85 in decimal, so 128-85 is 43
I am having a bit of trouble understanding Carry Flag (CF) and Overflow Flag (OF).
Here are some sample problems I am working on:
1. 1011 1111 2. 1111 0111 3. 0111 1110 --> 0111 1110
+ 1011 0111 + 1101 1101 - 1011 0000 --> + 0100 1111
___________ ___________ ___________ + 1
0111 0110 1101 0100 ___________
1100 1110
The carryout of the sign position is 1 and the carry in to the sign position is 0, so OF = 1?
The carryout of the sign position is 1 and the carry in to the sign position is 1, so OF = 0?
The carryout of the sign position is 0 and the carry in to the sign position is 1, so OF = 1?
I guess I am having trouble understanding an unsigned overflow and the appropriate CF value.
Disclaimer: I'm not an expert (or even a user of this level of code :) ).
I believe the carry-flag makes sense for unsigned data, and the overflow-flag makes sense for signed data.
Both will always be generated, but it is up to you to determine if you consider the values unsigned, or two's complement, so it is up to you which flag you pay attention to.
From: http://en.wikipedia.org/wiki/Overflow_flag
Internally, the overflow flag is usually generated by an exclusive or of the internal carry into and out of the sign bit. As the sign bit is the same as the most significant bit of a number considered unsigned, the overflow flag is "meaningless" and normally ignored when such numbers are added or subtracted.
The sign bit is the most significant bit (the one farthest left).
Exclusive or (XOR) is:
If neither: 0
If either: 1
If both: 0
Carry-in to the sign bit is when the 2nd most significant bits, when added, produce a value to be carried over to the next column.
Carry-out is whether carry must be done when adding the most significant bits (the sign bits, if the numbers are two's complement) together.
XOR those two values, and you should end up with the value for your overflow flag after a given addition.