MIPS addi signed interger - mips

I'm trying to solve the following problem:
Register $4 contains the 32-bit IEEE 754 representation of -31.5, what is the final result placed into $5 by the following instructions:
sll $5,$4,1
srl $5,$5,24
addi $5,$5,-127
$4 = 11000001 11111100 00000000 00000000
after performing sll $5,$4,1
$5 = 10000011 11111000 00000000 00000000
after performing srl $5,$5,24
$5 = 00000000 00000000 00000000 10000011
-127 = 11111111 11111111 11111111 10000001
From my understanding addi will take 16 bits of the immediate in this case 11111111 10000001 and add it to the register $5 value. Will the final value be 11111111 00000100 or 00000000 00000100 after adding both values?

Related

MIPS instruction modulo

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

Polynomial with x and y in MIPS

I just have a question on MIPS, I looked everywhere but I could not find examples of MIPS code with an x and y variable.. this is what I have so far, but I am unsure of how the .word 4 works as x = 4. Would I need another lw and sw for the y variable? Also, am I on the right track to solving 32xy + 15x−9y + 48? Thanks a lot!
#32xy + 15x−9y + 48
.text
.globl main
main:
lui $10, 0x1000 #load base register
lw $2, 0($10) #Store x in $2
ori $1, $0, 32 #store 32 in $1
ori $3, $0, 5 #store y(5) in $3 ### this is just temporary
ori $4, $0, 15 #store 15 in $4
ori $5, $0, -9 #store -9 in $5
ori $6, $0, 48 #store 48 in $6
multu $1, $2 #32 * x
mflo $7 #store 32*x in $7
mult $7, $3 #32x * y
mflo $7 #32xy = $7
multu $4, $2 #15 * x
mflo $8 #15x = $8
multu $5, $3 #-9 * y
mflo $9 #-9y = $9
addu $8, $8, $9 #15x - 9y = $8
addu $7, $8, $7 #32xy + 15x-9y = $7
addu $7, $7, $6 #32xy + 15x-9y + 48 = $7
sw $7, 4($10) #store result in poly
.data
x: .word 4
poly: .word 0

Two's Complement binary addition

I have a program that adds 2 two's complement binary numbers and spits out the output. They are read from a file as the first binary number being in two's complement. The second binary number being in biased notation. To change form biased to two's complement we flip the left most bit. We then add the two binary numbers and give the output to the file. What I am having trouble with is understanding the output. Here is the output where the first binary number is in two's complement and the second in biased notation.
01000000 <- 2's complement 64
+ 11000000 <- biased notation 64
-----------------------------------------------
10000000 <- 2's complement Overflow
01111111 <- 2's complement 127
+ 00000000 <- biased notation -128
-----------------------------------------------
11111111 <- 2's complement -1
00000011 <- 2's complement 3
+ 10000111 <- biased notation 7
-----------------------------------------------
00000110 <- 2's complement 6
00001111 <- 2's complement 15
+ 10000111 <- biased notation 7
-----------------------------------------------
00010010 <- 2's complement 18
10000000 <- 2's complement -128
+ 11111111 <- biased notation 127
-----------------------------------------------
11111111 <- 2's complement -1
11110000 <- 2's complement -16
+ 10001000 <- biased notation 8
-----------------------------------------------
11111000 <- 2's complement -8
10000001 <- 2's complement -127
+ 00000001 <- biased notation -127
-----------------------------------------------
00000010 <- 2's complement Underflow
01111111 <- 2's complement 127
+ 00000000 <- biased notation -128
-----------------------------------------------
11111111 <- 2's complement -1
01110101 <- 2's complement 117
+ 11010001 <- biased notation 81
-----------------------------------------------
01000110 <- 2's complement 70
00000000 <- 2's complement 0
+ 10000000 <- biased notation 0
-----------------------------------------------
00000000 <- 2's complement 0
00001111 <- 2's complement 15
+ 11110000 <- biased notation 112
-----------------------------------------------
01111111 <- 2's complement 127
00001111 <- 2's complement 15
+ 10000001 <- biased notation 1
-----------------------------------------------
00010000 <- 2's complement 16
00000111 <- 2's complement 7
+ 11110000 <- biased notation 112
-----------------------------------------------
01110111 <- 2's complement 119
11111111 <- 2's complement -1
+ 01111111 <- biased notation -1
-----------------------------------------------
10101010 <- 2's complement -86
00000000 <- 2's complement 0
+ 10000000 <- biased notation 0
-----------------------------------------------
00000000 <- 2's complement 0
11111111 <- 2's complement -1
+ 11111111 <- biased notation 127
-----------------------------------------------
00101010 <- 2's complement 42
Given the third example says 3 + 7 = 6.
Is this even correct? It doesn't seem right, but other examples are correct. Like -16 + 8 = -8.
So my question is... Is the output of this file correct?
It seems like whenever you have 3 carries in a row, it drops a 1. Same with the next one, 15 + 7. It isn't doing the carry correctly.
11 <- carry
0011 = 3
+0111 = 7
1010 = 10

Mips instructions mthi and mtlo into hex?

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

MIPS register instruction decoding

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.