before clas. The late policy applies to this lab project.
This lab is to be done individualy. Get started early! Also, remember to put your name on the
lab report! The required format for lab reports can be found in the resource web page.
Problem: Writing diagnostic programs
You are given a buggy version of SPIM, caled spim_broken (setup instructions below). 3 of
the 12 instructions you are asked to verify are buggy in some way or under some conditions. 9 of
the instructions always execute perfectly. Your task is to write a set of diagnostic programs to
identify the 3 buggy instructions, and to describe each bug. (You wil verify lots of other things
work. Include programs that confirm corect instructions too.)
Here is a list of things you should check for:
1. Register zero always has the value zero. Please test the case that the register zero is used
as both the target register and one of the source registers. (Note: Register zero may appear
to behave abnormaly for al instructions in the interactive mode, that is when you print the
value in the register zero, the register may contain non-zero values if the instruction just
executed writes to the register. The eror appears in both the correct version and the buggy
version of SPIM. It is related to how the register zero is implemented in SPIM. To bypas
this eror, please use only batch mode to test the value of register zero).
2. All the branch and jump instructions should jump to the right addres under the right
condition.
3. SLT(I) and SLTI(I) must work properly with bit paterns representing negative two's
complement integers or large natural numbers.
4. Al the arithmetic and logical instructions with imediate field should extend it properly.
5. Shifting instructions work corectly and extend the MSB appropriately.
You should make sure that the fundamental things work before you test some other things that
depend on them. Once you have verified that simple compares and branches work, you can build
longer programs with a sequence of tests. After each test, you can use a compare followed by a
branch to either go to the next test, or to a "failure label" which wil put in an identifier for the
failed test in a register. As long as there are no failures, it wil sequence through al the tests. You
can easily look at the "failure register" at the end of execution to determine which (if any) of the
tests failed. Your test code should look something like the following:
test case a
beq caseA_result, expected_Result, go_to_caseB
jump to failure A
caseB:
test case b
...
...
failure A:
addiu $t0, $0, 1
j endOfTest
failure B:
addiu $t0, $0, 2
j endOfTest
...
...
endOfTest:
A sample diagnostic program is provided. Writing diagnostic programs can deepen your
understanding of the instruction sets. The main purpose of this asignment, however, is not only
to refresh your knowledge of MIPS and understand the diagnostic proces. More importantly, this
lab is supposed to teach you how to create programs that can be used to validate your design
later in the semester, since the final project only requires you to implement your own ISA.
Therefore, diagnostic programs wil only be useful if they are writen using the limited set of
instructions that are available on a CPU. Hence, you must write the diagnostics using only the
MIPS instructions below:
arithmetic: addu, addiu
logical: and, or, andi
shift: sll, sra, srl
compare: slt, slti
control: beq, j
Helpful Hints
The 3 bugs were introduced by modifying a simulator, not by modifying hardware. Thus, do not
think in terms of "I think one shift opcode has a bug, and therefore the other shift opcodes must
have a bug too". Instead, you should think in terms of hunting for 3 independent bugs.
Just as a reminder, some of you wil find 6 or 7 opcodes with bugs, and you wil fel certain that
al of these bugs exist. In actuality, what is happening is that one of the instructions you think is
correct is in fact buggy, and that bug is deceiving you into thinking that correct instructions are
buggy.
What to Turn In
For this lab project, turn in al of your diagnostic programs. Describe the testing methodology that
motivates the design of your program suite. Tel us how your programs systematicaly test the
procesor, and explain why these tests were able to find the bugs you found.
Also, turn in a description of the specific erors that you found, and note which test program excited
each eror.
Point out the machine language instruction sequences in your diagnostic suite that tests each of the
"things you should check for" listed earlier in this section. Points wil be taken off if you did not
test for al of these items, even if you found al of the bugs! We want to se that you can design
systematic tests for an ISA.
In particular, don't ignore the list of "things you should check for", and just write tests for whatever
ideas came to mind.
How to Submit
Copy your lab report, which is a .pdf, a .doc, or a .html file, and al your source code into an
empty directory. Asuming the directory is "submision", make a tar bal of the directory using
the following command:
tar czvf [your_first_name]_[your_last_name]_lab1.tar.gz submision.
Replace [your_first_name] and [your_last_name] with your first name and your last name.
Use the submision function of Canvas to submit the tar bal file.
Setup Instructions:
Al files are located on mlb.acad.ece.udel.edu. First you need to copy exception.s to your work
directory. When you run spim or spim_broken, exceptions.s must be in the curent directory, that
is, the directory "./". Al the spim programs and exception.s can be found at /usa/xli/spim.
For mlb.acad.ece.udel.edu and other departmental linux machines:
spim_broken_linux: Buggy version of spim.
spim_linux: Correct version of spim.