I am stuck and unsure regarding the following situation.
I have the following datacycle:
and I know that in 0x3000 I have the following command: beq $t1,$t2,home - where home is 0x30AC, $t1=$t2=0x2000.
For some reason, I cannot translate it into hexa using online converters. The command I tried is: beq 0x2000, 0x2000, 0x30AC. Since the syntax of a beq command, as far as I know is: BEQ rs, rt, offset [I-type], then I don't understand why it doesn't work.
Anyways, my main problem are with the following cases:
If the control line of ALUSrc is stuck on 1, what will the command do?
If MemWrite is stuck on 1, what will the command do?
If ALUOp is stuck on the value 10 (binary), what will the command do?
What I think:
If alusrc equals one, then the lower 16 bits will be taken (with sign extenstion) from the command and added to $rs (0x2000).
If Memwrite equals one, then the data memory will be written unexpectedly.
I really don't know what will happen if ALUop will be stuck on 10. would really appreciate explanations regarding this situation.
I tried to elaborate as much as I can to make it understandable and also provide my attempts and insights (if correct, hope that some are lol).
Related
I have trouble implementing the movcn instruction in MIPS. (MIPS One-Cycle Datapath)
Here is how the instruction is defined:
R[rd] = R[rs] if R[rt] < 0
I am not sure what to use to compare if R[rt] < 0. Should I add a comparator in the path?
I think we're in the same UdeM class! Movcn isn't native to MIPS.
You already have a comparator in the datapath; the ALU. Consider that your read data 2 output from the Register File (RD2) should be changed to zero before being inputted into the ALU, if a certain signal is recieved indicating that the instruction is movcn.
I'm not gonna say anything else, but hopefully this helps you out enough to set you on the right track. Good luck with the homework, and godspeed.
I know that 0x00039 tells the computer that you are working with hexidecimal and I'm wondering if there's a binary version of the 0x...
For example, can I do:
li $t0, 10001
and let the the program know that I mean 17 and not ten-thousand and one?
I tried doing 0b10001 but it gave me an error.
According to this SO answer MIPS doesn't support binary, however, you might be able to use C macros to emulate it.
I'm struggling with this question:
Prompt the user to enter a number, print the number in 16-bit two's complement
To print the number you will print each bit as either the string "1"
or the string "0", using a loop that will print one bit in each
iteration. Start printing with bit 15. (Recall that we number the bits
starting from 0 at the low order bit.) In your loop test bit 15, and
then print either "1" or "0". Use a shift instruction to get the next
bit into position 15 before repeating.
I unfortunately missed a lecture that was about shifts and using masks, so I don't really have much understanding of how I would go about doing this lab. How can I print a specific bit of a number? I understand that I just keep printing bit 15, and then doing a shift left, but I have no idea this would be done in MIPS. Any help would be very much appreciated.
EDIT:
I understand the shifting perfectly, it's just printing the bit thats confusing me.
For example, if the number I wanted to convert to two's complement was 25 and is in register $t0.
First I print the 15th bit. Then I do a shift left. And then I repeat 15 times.
It should look something like this:
# Print bit
sll $t0, $t0, 1
I just don't get how to print the first bit at spot 15.
break down the problem --
1. how to print the bit, and
2. how to determine the bit's value
You already know how to determine the bit's value, you test bit 15 and keep shifting the other bits into position 15.
How are you expected to "prompt the user" to enter a value? Printing the bit is the same printing a prompt.
Masks are generally used with "bitwise and" or "bitwise or" instructions.
To determine whether a particular single bit is set to 1 in a number,
you take the "bitwise and" of that number with another number (the "mask")
in which that particular bit is set to 1 and all other bits are zero.
(There are other applications where you would want to set more than one bit in
a mask; better get a copy of those lecture notes!)
There are many places to look up the MIPS instruction set. For example, here
or here.
Find a page like those, then search for "shift left" and "bitwise and".
(And remember where you found that document so you can look up other things later!)
Background: We're seeing a very intermittent crash in a function foo(int *p). The crash occurs while dereferencing p, whose value in these cases turns out to be 0xffffffff. An analysis of the core dump shows that foo() is called from the following assembly snippet:
bne ... somewhere else
lw $a0,44(sp)
lw $a0,40(sp)
jal foo()
lui s1, 0x1000
Inspecting memory in the core dump shows that 44(sp) is 0xffffffff, whereas 40(sp) is the correct value we intend to dereference. However, the value of a0 at the time of the crash, inside foo(), is 0xffffffff. (It's important to note that foo() in this case is just accessing a member; so it's literally the first instruction in foo() which is already attempting to access via a0, and crashing. Also, ra is pointing to the instruction following the above snippet, and s1 currently contains 0x10000000, so we're quite confident that foo() was, indeed, called from the above snippet.)
Our only theory at the moment is that the two consecutive lws into a0 are a hazard -- either a documented one, in which case this looks like a compiler bug; or an undocumented one.
So: is the above assembly legal? If it is, any other ideas about what could be going on here?
Thanks!
UPDATE: Well, turns out this was all a wild goose chase: a repeat analysis of the coredump by a colleague turned up a path in the code which I had missed, where there was a jump directly to the jal foo() instruction, immediately after having set a0 to 44(sp). In other words, there is a path in the code which is consistent with the result we're seeing that does not involve hazards, or "skipped instructions" or anything... I thought I checked this, but I guess I either didn't, or missed it... :(
Anyway, I've accepted markgz's answer, since it answers my original question about the legality of these instructions (apparently they are).
A quick search of the MIPS documentation for the MIPS32R2 ISA doesn't show any restrictions on LW after LW instructions.
There might be a bug in the MIPS implementation in your CPU. Things to look at include:
What address is 44(sp), 40(sp) - are they on a page boundary or a 256MByte boundary, or other interesting address?
Do either of the loads trigger a page fault?
Does patching the binary to insert a NOP, SSNOP, or a SYNC instruction between the loads make the problem go away?
I am asked to add the shift left logical instruction to a single cycle datapath. I know I need to feed the SHAMT field to the ALU, but I'm not sure how to do this. I understand the basics of single cycle data paths for R-format, branch, load word, and store word, but I'm not sure how the SLL plays in... Can anyone help explain how a single cycle SLL datapath works?
If this is the wrong form for this post, I'd be much obliged if someone would direct me to the correct site.
You simply need to decode the opcode of the SLL instruction and use it to set the ALUOp input of the ALU to 11. You also need to set the multiplexers to put the source register and the shift amount at the appropriate inputs to the ALU.