MIPS How do I convert a j instruction to machine code? - mips

I need to convert this jump to binary and I can't figure out how to get the immediate value. I tried doing it by taking the base address of the Loop which was assumed to be 40000 then divide it by 4 (40000 / 4 = 10000) but I don't know if this is correct (That was just how they did it in an example in my book).
Loop: slt $t0,$s0,$s1
beq $t0,1,Exit
sub $s0,$s0,$s1;
j Loop;
Exit:

Bits 25..0 of the j instruction become bits 27..2 of the PC and bits 1..0 become 00 (this is the divide by 4 business). This works because addresses are always 4-byte aligned.
So if Loop is at address 40,000 then the bottom 26 bits of the instruction are 00 0000 0000 0010 0111 0001 0000 (10,000) and the other 6 bits are the j opcode (0000 10).
When the instruction executes the value (10,000 in your case) is extracted and shifted left 2 bits (which is multiplying by 4). Then this value replaces the bottom 28 bits of the PC -- the top 4 bits (0000 in your case) remain unchanged. The next instruction your program executes will be at address 40,000.

Related

MIPS Assembler "bne" Branch Address

I am working on an homework assignment which asks to translate the below MIPS instructions (highlighted in blue) into decimal, binary and hex equivalences, as well as to provide the local counter and program counter for each instruction. My answers are below in the white cells right below each instruction.
For the instruction bne $t9, $zero, next, I was told that the branch address is slightly off. Below steps are what I did to arrive at the answer:
Converted the bne opcode into decimal 5 according to the MIPS Green Sheet and then converted to its binary and hex equivalence
Converted the rs ($t9) and rt ($zero) into the decimals 25 and 0 according to the Green Sheet, respectively. Then, I converted them into their binary and hex equivalence.
Converted immediate code for the label "next" using the formula: PC = PC + 4 + BranchAddr. I rearranged the formula to Next Address = Current Address + 4 + Offset Address * 4 and finally to Offset Address = (Next Address - Current Address - 4) / 4. The label "next" is originally located at 0x04. Since the "bne" is currently located at 0x18, it is pointing at the address 0x1C. Thus the offset address is 0x04 (4 x 16 = 4) - 0x1C (1 x 16 + 12 = 28) = -24, the different is divided by 4 which results in -6. The result is then converted to it binary and hex equivalences.
I am not sure what is off here. Any help would be very much appreciated.

load byte instruction in MIPS

I am learning about Computer architecture through the MIPS instructions. I have a question which is:
Memory at 0x10000000 contains 0x80
Register $5 contains 0x10000000
What is put in register $8 after lb $8,0($5) is executed?
I was thinking when the load byte is called, it will take the 8 bits of 0x80[10000000] from the 0x10000000 address and load it into the first 8 bits of the $8 register and fill the remaining bits with zeros making the answer to be 00000080. But the correct answer listed is FFFFFF80. I am not sure if I understand it. Can anybody help explain it?
The instruction you mention here is lb which loads a one byte into a register by sign-extending the byte to the word size. This means if the most significant bit is set to 1 it will fill the remaining 24 bits with 1 as well. This is done to preserve the twos-complement value of the byte in a 32 bit representation.
If your byte would be 0100 1010 the sign-extend would fill it with 0 as
0000 000... 0100 1010.
If your byte would be 1011 0101 the sign-extend would fill it with 1 as
1111 111... 1011 0101.
To avoid this and always pad the byte with 0 you can use the alternative lbu instruction which does not perform a sign-extend but pads the byte with 0 instead.
This preserves the unsigned value of the byte since twos-complement is not involved for those.

MIPS PC and label tracking

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.

MIPS Multiplication with overflow follow by subtraction

The result of multiplication is stored in two different registers in mips high and low.
For Example: in this example i take high and low as 4 bit register for the sake of convenience.
li $t0,12
mult $t0,$t0
12 * 12 = 144
1100 * 1100 = 1001 0000
so the high has 1001 and low has 0000. now if i want to subtract 12 from the result. how do i do that?
i cant use
mflo $t1
subi $t2,$t1,12
because low has all zeros and the result would be wrong.How do i perform subtraction in this case.when two numbers are 32 bit integers and multiplication causes an overflow.say something like
2^30 * 2^4 - 14
the high register is used.
MIPS registers are 32-bit (or 64-bit, but that does not change results in this case), so after multiplication you will have hi=0x00000000 and lo=0x00000090. I.e. the 8 bits of product fit into 32 bits of lo just fine.
After subtracting 12 from 0x90 you should expect to see t2=0x84

Why do we need to Bit Extend the J type instruction to 2 bits only?

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