addi $1, $9, 1008, 9, 1, 100; converting to
binary gives
001000 01001 00001 0000000001100100;
converting to hexadecimal gives 21210064.
lui $s1, 010$s1 is really register
$17. Fields from p. A-59 are
0xf, 0, 17, 8; converting to binary gives
001111 00000 10001 0000000000001000;
converting to hexadecimal gives 3c110008.
slt $5, $a1, $t1$a1 is really register
$5 and register $t1 is really register
$9. Fields from p. A-60 are
0, 5, 9, 5, 0, 0x2a;
converting to binary gives
000000 00101 01001 00101 00000 101010;
converting to hexadecimal gives 00a9282a.
sw $9, 200($s3)$s3 is really register
$19. Fields from p. A-67 are
0x2b, 19, 9 100. Converting to
binary gives
101011 10011 01001 0000000011001000;
converting to hexadecimal gives ae6900c8.
beq $12, $17, 0x100 (assume 0x100 is
the actual offset to the target instruction.4, 12, 17, 25;
converting to binary gives
000100 01100 10001 0000000000011001;
converting to hexadecimal gives 11910019. From
questions people asked me, it looks like it wasn't clear what I
meant by offset. People who assumed the offset was from the
current instruction rather than the following instruction and
got 11910018 will also get credit.
sge $5, $6, $7sge $5,$6,$7 is just the opposite of
slt $5,$6,$7. So we can do this in two
instructions as
slt $5,$6,$7
xori $5,$5,1
From pp. A-59 and A-60, the fields for these instructions are
0, 6, 7, 5, 0, 0x2a
0xe, 5, 5, 1
Converting to binary gives
000000 00110 00111 00101 00000 101010
001110 00101 00101 0000000000000001
and converting to hexadecimal gives
00c7282a
38a50001
It was an unpleasant surprise to discover SPIM generates four
instructions, including two branches, to do the same thing
(unless I'm missing something major in my code...).
li $5, 0x1234abcd
lui $5, 0x1234
ori $5, $5, 0xabcd
From pp A-57 and A-59, the fields are
0xf, 0, 5, 0x1234
0xd, 5, 5, 0xabcd
Converting to binary gives
001111 00000 00101 0001001000110100
001101 00101 00101 1010101111001101
Converting to hexadecimal gives
3c051234
34a5abcd
Nice to see SPIM did this one the same way I did (though it used
$at as the temporary).
abs $3, $a3
add $3, $a3, $0
bgez $3, 8
sub $3, $0, $3
Looking up the register numbers on page A-23 and the instruction
fields on pp A-55, A-59, and A-62 gives us
0, 7, 0, 3, 0, 0x20
1, 3, 1, 2
0, 0, 3, 3, 0, 0x0x22
In binary this becomes
000000 00111 00000 00011 00000 100000
000001 00011 00001 0000000000000010
000000 00000 00011 00011 00000 100010
And in hexadecimal it's
00e01820
04610002
00031822
Again, equivalent to SPIM's solution.
Assume the instructions in the first problem are a program,
starting at address 0x400. At the end of the first
cycle of execution, the PC will contain 0x404, the
first instruction has been read into the IF/ID pipeline
register, and the contents of the rest of the data paths are
unknown. Show the contents of the data paths following cycles
2, 3, 4, and 5. I don't think I created any hazards with the
sequence of instructions I gave you; if I did, just ignore
them. Give the contents of every field of
every pipeline register that you can determine, whether
it's useful to the instruction or not. Follow the assumptions
for problem 6.10 in the book for initial register comments,
except the PC (which I gave you above).
You'll probably want to make several photocopies of the top half of page 452. Please scale them up to fill a whole page!
In the MIPS as described so far, it is impossible to implement an
addiu instruction. Why? Add a mux to make it
possible.