Is there a way to store the 16 leftmost bits, and the 16 rightmost bits of a binary number in MIPS?
For example, let's say I have the binary number: 1111 1111 1111 0000 0011 1111 0011 1100. Now, I want to store 1111 1111 1111 0000 in $t0 and the other half in $t1. Is there a way to do that? Thanks!
Related
I need to initialize an register with an specific decimal value in order to extract the bits of another register (by doing this). The only problem is, since I need to do an andoperation with a very large decimal, it turns out to be very difficult to convert a binary number into a decimal number without a calculator to perform this operation.
So I am interested to know if there is any way of initializing a register with a binary value directly
If your assembler/simulator does not allow you to write binary constants but it allows you to write hexadecimal ones then you may easily encode a binary number in hexadecimal.
Starting from the least significand bit, every 4 bits you encode its hexadecimal value using the following table:
0000 - 0
0001 - 1
0010 - 2
0011 - 3
0100 - 4
0101 - 5
0110 - 6
0111 - 7
1000 - 8
1001 - 9
1010 - A
1011 - B
1100 - C
1101 - D
1110 - E
1111 - F
If the original binary number does not have a multiple of 4 bits you fill the most significand bits to 0 until it fills the last packet.
For example, you may encode this words in hexadecimal converting them from binary numbers:
myvar: .word 0x1234 # binary 1 0010 0011 0100
other: .word 0xCAFEBABE # binary 1100 1010 1111 1110 1011 1010 1011 1110
I have this example:
If we take the binary representation of the decimal value 220 (1101 1100) and we wanted to extract the higher 4 bits, we could use a bitmask with the boolean AND operation:
1101 1100 (220)
AND 1111 0000 (240)
_________
1101 0000 (208)
I need to know how to get 240.
2**7 + 2**6 + 2**5 + 2**4 = 240
Where ** is exponentiation.
I'm really confused about the term "32-bit twos complement"
If I have the number 9, what is the 32-bit twos complement?
9 = 1001
Two's complement = 0111
32-bit 9 = 0000 0000 0000 0000 0000 0000 0000 1001
Two's complement = 1111 1111 1111 1111 1111 1111 1111 0111
That result is so ridiculous! It's way too large! Is that really how you're supposed to do it?
The most common format used to represent signed integers in modern computers is two's complement. Two's complement representation allows the use of binary arithmetic operations on signed integers.
Positive 2's complement numbers are represented as the simple binary.
Negative 2's complement numbers are represented as the binary number that when added to a positive number of the same magnitude equals zero.
Your 2's complemented output is equivalent to -9 (negative 9).
Edited:
You are asked to perform 32-bit operation hence it should be 1111 1111 1111 1111 1111 1111 1111 0111
For signed number, leftmost bit represents the sign of the number. If leftmost bit (LSB) is 1 then the number is negative otherwise it's positive. So, your 32-bit 2's complemented number is negative and it's -9. Simply, performing 2's complement on a number is equivalent to negating it
i.e. it makes a positive number into negative and vice versa.
For more browse the link:
http://www.tfinley.net/notes/cps104/twoscomp.html
Let's say I want to convert "-128" into binary.
From what I understand, I get the binary representation of "128", invert the bits and then add 1.
So 128 = 10000000
So the "inverse" is 01111111
So and "01111111" + "1" = "10000000" which is "-0" isn't it?
My textbook makes this seem so easy but I can't figure out what I'm doing wrong. Thanks for the help.
No, that's definitely -128 (in two's complement anyway, which is what you're talking about given your description of negating numbers). It's only -0 for the sign/magnitude representation of negative numbers.
See this answer for details on the two representations plus the third one that C allows, one's complement, but I'll copy a snippet from there to keep this answer as self-contained as possible.
To get the negative representation for a positive number, you:
invert all bits then add one for two's complement.
invert all bits for one's complement.
invert just the sign bit for sign/magnitude.
You can see this in the table below:
number | twos complement | ones complement | sign/magnitude
=======|=====================|=====================|====================
5 | 0000 0000 0000 0101 | 0000 0000 0000 0101 | 0000 0000 0000 0101
-5 | 1111 1111 1111 1011 | 1111 1111 1111 1010 | 1000 0000 0000 0101
You should be aware that there is no 128 in 8-bit two's complement numbers, the largest value is 127.
Where the numbers pass the midpoint is where the "clever" stuff happens:
00000000 -> 0
00000001 -> 1
: :
01111110 -> 126
01111111 -> 127
10000000 -> -128
10000001 -> -127
: :
11111110 -> -2
11111111 -> -1
because adding the bit pattern of (for example) 100 and -1 with an 8-bit wrap-around will auto-magically give you 99:
100+ 0 0110 0100
1- 0 1111 1111
===========
1 0110 0011 99+ (without that leading 1)
It depends on what your binary representation is -- ones complement, twos complement, sign-magnitude, or something else. The "invert bits and add 1" is correct for twos complement, which is what most computers these days use internally for signed numbers. In your example, "10000000" is the 8-bit twos-complement representation of -128, which is what you want. There is no such thing as -0 in twos complement.
For sign-magnitude, you negate by flipping the sign bit. For ones complement, you negate by inverting all bits.
I'm trying to understand these illustrations but there are parts which I don't understand:
"But the computer had to count backwards for the negative numbers"
Why does adding a 1 to the front of a binary mean the computer has to count backwards?
"Flip the bits and add 1!"
What does that mean add 1?
woops: http://csillustrated.berkeley.edu/PDFs/integer-representations.pdf
This may be easiest to show by example. Here are the numbers from -4 to 4 represented in binary:
4 0000 0100
3 0000 0011
2 0000 0010
1 0000 0001
0 0000 0000
-1 1111 1111
-2 1111 1110
-3 1111 1101
-4 1111 1100
So say we want to go from 1 to -1. We first flip all the bits of 1
1 0000 0001
flip bits
-----------
1111 1110
Then we add a 1:
1111 1110
+ 1
-----------
1111 1111
We now have -1.
I'm not seeing the illustrations, but you're probably talking about Two's complement representation. (http://en.wikipedia.org/wiki/Two's_complement)
Why does adding a 1 to the front mean the computer has to count backwards?
Due to how carrying works, FFFFFFFFF + 1 == 0
and 0 - 1 == FFFFFFFF. All the bits get flipped, including the first bit.
If you simply define the negative numbers as those starting with a 1 bit (80000000 - FFFFFFFF) then you get a nice uniform behavior for addition with a natural overflow.
Flip the bits and add 1: in 2's complement, this negates a number
~x+1 == -x; // always true
What you're talking about is called signed integers.