Write a MIPS program that asks the user to enter an unsigned number and read it. Then swap the bits at odd positions with those at even positions and display the resulting number. For example, if the user enters the number 9, which has binary representation of 1001, then bit 0 is swapped with bit 1, and bit 2 is swapped with bit 3, resulting in the binary number 0110. Thus, the program should display 6.
the answer must be MIPS code
just XOR the target number with a 1 string of the same length, eg to flip 1010, 1010 XOR 1111 = 0101 docs
Related
Let's say I want to add 4 binary numbers in 2's Complement: a+b+c+d. I have a circuit that can add 2 binary numbers at a time, and that detects whether overflow has occurred for the corresponding sum (by using XOR with the last carry bits).
When adding multiple numbers in 2's Complement, it is possible that the intermediate sums overflow, while the final result does not. For example:
4 + 5 + (-6) expressed with 4 bits and C2:
0100 +
0101
====
1001 (-7 : overflow)
1001 +
1010
====
0011 (3, the correct result)
My question is: how can I know, when adding 4 binary numbers with N bits, whether the final result overflows or not? Is there any logical expression or circuit that can automatically detect when overflow occurs?
In your example, 0100 + 0101, represented with 4 bits, gives the hardware result of 1001.
It is now up to you how you interpret these bits.
If you interpret them as 2’s complement integers, the result is wrong (decimal -7, overflow).
If you interpret them as unsigned integers, the result is correct (decimal 9).
If you add then 1010, you have to think about how to interpret these bits.
Unsigned, they are decimal 10, 2’s complement, they are decimal -6.
Still, it is up to you, how you interpret the result. It is 0011 plus a carry bit, since 1001 + 1010 gives 10011.
Thus the problem arises because you change the interpretation of the bits during the computation.
This cannot be handled by any logical expression or circuit.
I have just started doing some binary number exercices to prepare for a class that i will start next month and i got the hang of all the conversion from decimal to binary and viceverca But now with the two letters 'a ' ' b' in this exercise i am not sure how can i apply that knowledge to add the bits with the following exercise
Given two Binary numbers a = (a7a6 ... a0) and b = (b7b6 ... b0).There is a clculator that can add 4-bit binary numbers.How many bits will be used to represent the result of a 4-bit addition? Why?
We would like to use our calculator to calculate a + b. For this we can put as many as eight bits (4 bits of the first and 4 bits of the second number) of our choice in the calculator and continue to use the result bit by bit
How many additions does our calculator have to carry out for the addition of a and b at most? How many bits is the result maximum long?
How many additions does the calculator have to perform at least For the result to be correct for all possible inputs a and b?
The number of bits needed to represent a 4-bit binary addition is 5. This is because there could be a carry-over bit that pushes the result to 5 bits.
For example 1111 + 0010 = 10010.
This can be done the same way as adding decimal numbers. From right to left just add the numbers of the same significance. If the two bits are 1+1, the result is 10 so that place becomes a zero and the 1 carries over to the next pair of bits, just like decimal addition.
With regard to the min/max number of step, these seems more like an algorithm specific question. Look up some different binary addition algorithms, like ripple-carry for instance, and it should give you a better idea of what is meant by the question.
Assuming that the current PC is 0x00400010 (after increment) and the target label has the value of 0x00400040. What is the binary value of the constant in the instruction?
beq $s0, $s0, target
I'm not really sure how to approach this question. I would appreciate a hint, or explanation of how to find a solution to this.
I am not sure if I have understood your question. I am assuming that you are asking for the offset which will be coded into the instruction.
Since the target is at 0x00400040 and the current PC is at 0x00400010, the offset probably will be 0x00000030 (because 0x00400040 - 0x00400010 = 0x00000030). This can be easily converted into the binary format you asked for:
0000 0000 0000 0000 0000 0000 0011 0000
But please note that I don't know MIPS. In some processor architectures, the offset coded into the instruction is
(target PC) - ((current PC) + (size of current instruction))
Since I don't know MIPS, I don't know what the byte size of the beq instruction is. Thus, I can't compute the offset for this case. If you tell me the size of the beq instruction, I'll make an edit to that answer and add that.
Furthermore, in most processor architectures, relative offsets will be restricted for most instructions. Once again, I don't know MIPS, but chances are that the offset is limited to 16, 12 or even 8 bits. In that case, to get the actual binary offset representation, remove zeroes from the left from the binary number I gave above until only the bits which are used to store the offset are left.
EDIT (taking into account Busy Beaver's comment)
On MIPS, it seems that instructions are aligned to 32 bits / 4 bytes. This allows to store the actual offset needed divided by 4 (the CPU then reads the offset and multiplies it by 4 to compute the actual target). The advantage is that you can store bigger offsets with the bits given. In other words, you save 2 offset bits that way.
In your example, the PC should jump by 0x00000030 bytes to get to the target. The offset stored in the instruction then would be 0x00000030 / 4 which is the same as 0x00000030 >> 2 which is 0x0000000C0. You asked for the binary representation:
0000 0000 0000 0000 0000 0000 0000 1100
When decoding / executing the instruction, the CPU automatically multiplies that offset by four and that way gets back the real offset desired.
Based on my statements below I have few questions. Please explain.
Q1. Why the output is same for items 2 and 4. I guess it is because byte 128 is equal to byte -128
Q2. Why the output for items 2 and 4 are padded with 1s on the left where the output is supposed to be just this 10000000. I guess.
Q3. What is the difference between outputs 2 and 3 even though the last out 8 bits looks same.
1. System.out.println("1==>"+Integer.toBinaryString((byte)127));
2. System.out.println("2==>"+Integer.toBinaryString((byte)128));
3. System.out.println("3==>"+Integer.toBinaryString(128));
4. System.out.println("4==>"+Integer.toBinaryString((byte)-128));
output :
1==>1111111
2==>11111111111111111111111110000000
3==>10000000
4==>11111111111111111111111110000000
A byte in Java is actually a signed 8-bit integer. It can only represent numbers from -128 to 127.
Q1. 128 is an overflow. It becomes -128.
Q2. Both these are negative numbers. For negative numbers, the method returns "the argument plus 2^32". This results in a lot of leading 1s. For positive numbers, the output just omits the leading 0.
Q3. In example 3, you don't use a byte. You use int. This means you can represent 128, it is not an overflow.
Please have a look at this Single Cycle Data Path in MIPS. The 26 bits of J type instruction are being Bit Extended to 28. I don't get the point. Shouldn't it be extended to 31 so it makes 32 bits overall. Please help me out to clear the concept.
Thanks
This is really no sign extension. Recall that the instructions in MIPS are 4-byte aligned.
This means that you can start an instruction at addresses which are 0 modulus 4 (i.e. 0, 4, 8, 12, ...)
Now, doing a shift left of 2 two bits is like multiplying by 4, which yields numbers which are always 0 modulus 4.
The actual address will be formed with:
- the 4 most significant bits of the nPC (that is PC+4) (lets call them PPPP)
- the 26 bits of the address field specified in the instruction, (lets call them AAA....AA)
- 00 as the two least significant bits (which yields the required instruction alignment)
Thus the address will be (binary) PPPPAAAAAAAAAAAAAAAAAAAAAAAAAA00