I am in the process of writing a utility to convert a mips instruction into its hex (4 bytes) format. Everything was going ok with instructions such as ADD, etc. But with mthi and mtlo, there is a different in the output I am getting compare to what is expected. I am not sure what exact version of mips this is.
Here is what I am getting:
mthi $t2 = 01400011
mthi $s0 = 02000011
mtlo $t8 = 03000013
mtlo $a3 = 00e00013
Here is what I am getting:
mthi $t2
1010 00000 00000 00000 010001
Does anyone know how the inner bits are being calculated and what version of mips that is? Thanks.
Information from "See MIPS Run", for all MIPS ISA it covers (up through MIPS IV) there is no difference in the MIPS32 instruction.
This is the format for mfhi, mtlo, mfhi, mtlo (mfhi/mflo included for comparison and completeness)
bit: 31-26 25-21 20-16 15-11 10-6 5-0
mfhi rd 0 0 0 rd 0 16
mthi rs 0 rs 0 0 0 17
mflo rd 0 0 0 rd 0 18
mtlo rs 0 rs 0 0 0 19
So mthi $t2 (register #10)
mthi $t2 000000 01010 00000 00000 00000 01001
The MIPS 32R2 encoding of MTHI rs is binary 000000 sssss 000 0000 0000 0000 010001.
So MTHI $t2 is binary 000000 01010 000 0000 0000 0000 010001
Related
I don't know how to translating mips I-format instruction to binary.
For example,
$t0 is base of an int array A[].
And the way to get value of A[1] is
lw $t0, 4($t0) // 4 means 4bytes
35(6bits) | 8(5bits) | 8(5bits) | 4(16bits)
10011 / 00101 / 01000 / 0000 0000 0000 0100
Is it correct?
and
bne $t0, $s0, Exit <- 80000
// other instruction1 <- 80004
// other instruction2 <- 80008
Exit: <- 80012
5(6bits) | 8(5bits) | 16(5bits) | 2(16bits)
00101 / 01000 / 10000 / 0000 0000 0000 0010
Pointer counter points instruction1(80004).
And address is byte address.
Is correct?
I know address in BNE is instruction distance between Program Counter.
I am confused why address in BNE is 2, not 8.
lw $t0, 4($t0) // 4 means 4bytes
35(6bits) | 8(5bits) | 8(5bits) | 4(16bits)
Yes
10011 / 00101 / 01000 / 0000 0000 0000 0100
No
100011 / 01000 / 01000 / 0000 0000 0000 0100
bne $t0, $s0, Exit <- 80000
5(6bits) | 8(5bits) | 16(5bits) | 2(16bits)
Yes
00101 / 01000 / 10000 / 0000 0000 0000 0010
Close
000101 / 01000 / 10000 / 0000 0000 0000 0010
(Make sure there's actually 6 digits in your 6-bit fields.)
With MIPS, all instructions are 32 bits wide, or 4 bytes long, and each instruction starts at an even 4 byte boundary (4 byte or word aligned, even multiple of 4). Thus, for a branch, it is going from a 4 byte aligned address to another 4 byte aligned address.
A 4-byte aligned address has 2 low bits of zero. The branch offset is the difference between 2 4-byte aligned addresses, and therefore such an offset also has 2 low bits that are zero. There's no point in encoding those two zero bits in the instruction because it is known they're zeros. So, the immediate encoded in the branch instruction is the branch offset divided by 4, which removes those zero bits, and also increases the branch offset's range by 2 bits. (The assembler divides the offset by 4 to encode it and the hardware effectively multiplies the immediate by 4 in usage.)
b = a % 16
a --> $s0
b --> $s1
Answer: $s1, $s0, 0xF
#0xF= 0000 0000 0000 0000 0000 0000 0000 1111
When I convert it to decimal, it is 15.
I am not too sure why it is 15?
The remainder when dividing any number by b is in the range [0, b-1]. So modulo 16 returns a maximum value of 15
To get modulo 2N of any number we take the last N bits of it, because any higher bit at position M with M > N represents a value 2M which is divisible by 2N. The mask to get N bits is 2N - 1. That means a % 16 = a & 0xF = a & 15
When using the MIPS command div for division, the result is stored in the register lo while the modolo is stored in the register hi.
So if a=$s0, b=$s1 and $t0 = 16 you could use
div $s0,$t0
mfhi $s1
for b=a%16
I'm trying to adapt a program that counts the occurrences of a char in a file to store a list of the hex addresses where the matches occurred in a far-off memory location. Code:
011 0000 0000 0000 ;Codes x3000 as Load-address of program
0101 010 010 1 00000 ;R2 <- 0
0010 011 000010000 ;R3 <- M[x3012]
1111 0000 0010 0011 ;TRAP x23 (Loads INPUT into R0)
0110 001 011 000000 ;R1 <- M[R3]
;LOOP BEGINS HERE
0001 100 001 1 11100 ;R4 <- R1 - EOT
0000 010 000001000 ;If above = 0, exit loop
1001 001 001 111111 ;R1 <- NOT R1
0001 001 001 1 00001 ;R1 <- R1 + 1
0001 001 001 0 00 000 ;R1 <- R1 + R0
0000 101 000000001 ;If above != 0, do NOT increment counter
0001 010 010 1 00001 ;R2 <- R2 + 1 (increment counter)
0001 011 011 1 00001 ;R3 <- R3 + 1 (increments pointer to next char in file)
0110 001 011 000000 ;R1 <- M[R3] (loads next char into R1)
0000 111 111110110 ;BRnzp x3004 (unconditionally RETURN to loop start)
;LOOP ENDS HERE
0010 000 000000100 ;R0 <- M[x3013]
0001 000 000 0 00 010 ;R0 <- R0 + R2
1111 0000 0010 0001 ;TRAP x21 (OUTPUT)
1111 0000 0010 0101 ;TRAP x25 (HALT)
0011 0001 0000 0000 ;Codes x3100 for the starting address of the file
0000 000 000110000 ;ASCII template
So my program starts at memory address x3000. I want to begin the set of instructions that will handle the list at x300B (below the "increment R2" instruction). Trouble is, I want to start the list at x3500, and I don't know of an "efficient" way to get there.
My original plan was to use a Load Indirect (LDI) instruction, but because of sign-extension, the 9-bit offset only allows an offset of at most x00FF = 0000 0000 1111 1111, which only takes me from x300C (x300B with program counter incremented) to x310B.
The only real "workaround" I've come up with is to use a Load Effective Address (LEA) instructions to store the address x310B in a register (say R5), then store the value x00FF in R6, and repeatedly add R6 to R5 until I get to x3408 (that would take 3 ADD instructions), at which point I'd store the value x0092 in R6, add that to R5, and I'd FINALLY have x3500 in R5.
At that point, the rest is trivial (store R3 in (R5 + counter), which would put the address of the current match into the appropriate "spot" on the list)
I haven't actually done this yet because the whole method of getting to x3500 I described above seems really cumbersome and clumsy. I can't shake the feeling that there has to be a better, faster way to move that many memory addresses at the same time.
Is it possible to move from x300C to x3500 in a single instruction? Even two would be better than what I've currently got.
You wouldn't want to do that, it is possible but a simpler method would be to use LD (opcode 0010) and LDR (opcode 0110) to do this. No need to have the PC jump to x3500 (which would start executing the data in your array which is bad)
Have an address contain the bits 0011 0101 0000 0000
Opcode 0010 will allow you to pull the x3500 into a register. Opcode 0110 will then allow you to load values from your array.
Im trying to get the number of 1's on the left side (bits 16-31) This code seems to work but im getting 1 extra count on my 1's from certain integers.
For example:
1536 in binary is 0000 0000 0000 0000 | 0000 0110 0000 0000
and im getting 0 1's on the left side which is correct.
Also:
100000 left side binary is 0000 0000 0000 0001
and my result is 1. which is also correct.
However:
1000000000 in binary is 0011 1011 1001 1010 | 1100 1010 0000 0000
and im getting 10 1's on the left side instead of 9.
Ive tested other numbers as well but they also have an extra count.
#Displays number of 1's on left half
li $v0, 4
la $a0, left
syscall
li $t2, 0 #i = 0
srl $t3, $s0, 16 #shifts users number to the right by 16 bits
Counter:
and $t4, $t3, 1 #Mask off bit
beq $t4, 1, Count #if mask = 1 go to count
srl $t3, $t3, 1 #if mask != 1 (aka 0) shifts right by 1
beq $t3, 0, Exit #once the shifted bits = 0 go to exit
Count:
add $t2, $t2, 1 #increment i++
srl $t3, $t3, 1 #shifts right by 1
j Counter
Exit:
li $v0, 1 #Displays number of 1's
move $a0, $t2
syscall
Not sure if the code is even correct since im new to mips. Could be possible that the whole thing is wrong.
You may use clz/clo to count the number of leading zeros and ones, and use that to count the number of ones. The idea is to consume the leading zeroes, then count the leading ones (shifting those bits out of the register) until the input data is zero.
i.e.:
li $t1, 0x4F044321 % $t1 Input number
srl $t1, $t1, 16
sll $t1, $t1, 16 % Discard least significant bits
li $t2, 0 % $t2 will hold number of 1s
count:
beqz $t1, done
clz $t3, $t1
sllv $t1, $t1, $t3
clo $t3, $t1
addu $t2, $t2, $t3
sllv $t1, $t1, $t3
b count
done:
I've decode the three MIPS registries under here, but I'm not sure if I'm applying the theory correctly.
Could someone confirm my answers and perhaps shed some light on decoding the first address?
0010 34422345 ori $2 , $2 ,0 x2345
0018 24020007 li $2 ,7
002c 00621021 addu $2 , $3 , $2
1st = opcode: 13; rs: 18; rt: 18;
2nd = I-type: opcode 8; rs 18; adress 7;
3rd = R-type: opcode 0; rs 18; rt 19; rd 18;
Your numbers look a bit off. These are my interpretations:
1) I-type
0x34422345
001101 00010 00010 0010001101000101 (binary)
op (13) rs (2) rt (2) imm (0x2345)
=> ori $v0,$v0,0x2345
2) I-type
0x24020007
001001 00000 00010 0000000000000111
op (9=addiu) rs (0) rt (2) imm (7)
=> addiu $v0,$zero,7
3) R-type
0x00621021
000000 00011 00010 00010 00000 100001
op (0) rs (3) rt (2) rd (2) shift function (33)
=> addu $v0,$v1,$v0
Here's a list of opcode/function numbers.