15-347/18-347 Spring '97
Notes on Assignments and Exams
In the following, the term HOME347 refers to the home directory for the course, namely
/afs/cs.cmu.edu/academic/class/15347-s97/public.
The following information is in reverse order of
assignment and exam, i.e., the most recent assignments and
exams appear first.
Homework 4
The description of this assignment is available in postscript form. You will need to
examine the video clips with a program that can play Quicktime format
videos. Here are some options:
- The xanim program is available on most of the campus
Unix machines.
- You'll want to work directly from a workstation rather
than operate remotely with a server machine.
- The SUN's in the Wean
Hall cluster work well, but they seem to have their sound disabled.
For the parts of the assignment where you need to check the sound quality, you'll have to move to a different machine.
- Xanim runs very nicely on the Wean Hall SGI machines
- The SGI program movieplayer. This is a nice program,
but it doesn't generate some of the quantitative information this
assignment requires. You can get some useful information with the
program mediaconverter.
- The Macintosh program
Movie Player. Again, it gives a very good display, but not
enough quantitative information.
- For those of you with a PowerPC
Macintosh, try installing the program MovieInfo Pro that I
downloaded from the Internet. You can do a frame-by-frame analysis of
the video. The documentation is in Japanese, but the program interface is in English.
- There should be comparable programs on most other platforms.
Lab 3
The description of this assignment is available in
(postscript form). Observe that there are two due dates: Thursday, April 17 for the simulator code and Tuesday, April 22 for the rest.
Grade histogram for Exam 2
78 points. Mean=55, Median 57
Last last year's Exam 2
(postscript).
Homework 3
Solutions are now available.
(postscript).
Lab 2
We are giving students a chance to improve their grades on this assignment by fixing and resubmitting their code. You should:
- Fix your bugs. Feel free to run the tests in
HOME347/public/labs/lab2/microtests. You should not get any
error messages, and the program should halt on "break 1".
- Turn in your code by copying the file to the directory:
/afs/andrew.cmu.edu/scs/cs/15-347/lab2-new-handins
- Name the file as before: NAME-stages.c, where NAME is the same
one you used on your first handin
- You have until 3:00pm Thursday, April 10 to do this.
We will:
- Rerun our tests
- Derive a "correctness measure" Cnew based on the same method as before.
That is, for each of the two modes, there are up to 25 points of correctness,
but you lose 1 point for each failing test. So, Cnew can range from
0 to 50.
- Suppose your old correctness score was Cold (also between 0 and 50).
- We will add to your original score 0.75 * (Cnew - Cold) points.
- For example, if you had Cold = 0 and Cnew = 50, you'll get 37.5
points.
In addition, if you missed points in the "coverage" section of the testing (max. 8 points),
and you can show me that you really did run a set of tests to cover
all the different hazards, I will give you credit for some of those
points. You can show me the code you used to generate your tests, or
the directory containing your tests as proof of this.
Important Announcement: The due date for this assignment has been extended to Tuesday, March 11.
The documentation for the assignment is available in
postscript.
The files you need for Lab2 are available as
HOME347//public/labs/lab2/files.tar
You can try out a working version of the simulator solve_tk in the directory
HOME347public/sim/. Included in this directory are subdirectories containing tests cases:
- demos containing the demonstration examples from the Feb. 20 class.
- exc containing the demonstration examples for the Feb. 25 class on exception handing.
- tests containing the demonstration examples for the Feb. 25 class on exception handing.
If you use one of the servers, e.g., by telnetting to sun4.andrew or
to hp.andrew, you'll need to enable that machine (the "client") to
open an X window on your machine (the "server"). To do this,
determine the name of the server (e.g., unix26.andrew.cmu.edu), and
give the command to the console of your own machine:
xhost unix26.andrew.cmu.edu
You can test for X window problems by attempting to execute the
command xterm on the remote machine.
Clarifications
- In the actual MIPS instruction set, the jalr has two register operands: one to specify the jump destination, and the other is the return pointer. In our simulator, we will assume the return pointer is always $31.
Some advice:
This lab is going to take time.
If you try to start the night before, you'll find yourselves in
deep trouble. In particular, note that the quality of your testing
procedure (task 4) is going to count a significant fraction (around
30%) of the total. If you're still trying to understand C code and
add forwarding the night before the assignment is due, you're going to
have to blow off this important part of the assignment.
Here's my advice on how to proceed:
- Try running the executable version on the class demos
(demos/demoX.O) and the supplied test code (tests/XXX.O). Make sure
you understand what is happening, especially how the various hazards
are handled in both stall and forwarding mode.
- Study the code in stages.c carefully. It closely parallels the
pipeline organization presented in Ch 6 of the text and in lecture.
- Implement the jump instructions. You'll need to think
through how to compute the target address and how to deal with register
31 (for jal and jalr). Test them on code examples that don't have any
hazard problems.
- Implement stall mode. It requires only adding some code to
the procedure do_stall_check.
- Implement forwarding mode. This involves changes to do_ex_stage,
do_mem_stage, and do_stall_check.
- See what kind of fault coverage you're getting from the supplied
tests. For data hazards, you can be systematic, filling in the matrix
shown in class (Lect. 10, Slide 24). It's hard to be systematic about
control hazards. But think through different aspects of branches and
jumps that need to be tested.
- Devise a comprehensive test set, based on your analysis from 6.
To implement jump instructions and forwarding, you'll need to embellish the design presented in the book and in the lecture. In doing so, you should keep in mind the following:
- It's OK to add more "wiring", multiplexors, and control logic.
- It's not OK to add more ALUs or adders.
- You must obey the register usage constraints: only one stage can
set the next state of a pipe register, but many can read the current
state.
- You must not introduce "hidden" state into your program in the form of static global or static variables.
Grade histogram for Exam 1
70 points. Mean=47, Median=49.
Lab 1
Lab 1 is available in HOME347/labs/lab1. Hardcopies can be
picked up from the course secretary.
Disassembled code for #5
It turns out that even a small, seemingly trivial change in your C
code can make cc decide not to do software pipelining anymore. Since
this means that some perfectly reasonable solutions to problem 4 don't
yield software-pipelined code when compiled with cc for problem 5,
we've decided to give you the disassembled code that we want you to
start with.
If your code did get cc to do software pipelining, and you've already
written the C code to match it, don't do it again. However, be sure
you indicate clearly that you used your disassembled code and not
ours, so that we'll grade it properly.
Revised load/store count estimates
On a DECstation (I used ride.ww), you can eliminate...
problem # outer loop inner loop
2 2 L, 0 S 3 L, 0 S
3 0 L, 0 S 3 L, 2 S
4 1 L, 0 S 0 L, 0 S
On an SGI (I used dakota.weh), you can eliminate...
problem # outer loop inner loop
2 3 L, 0 S 3 L, 0 S
3 0 L, 1 S 2 L, 1 S
4 1 L, 0 S 0 L, 0 S
The abbreviation "x L, y S" means x loads, y stores.
BEQL and BNEL instructions
In the last problem of Lab 1, you're asked to compile your C code
with CC on an SGI and look at the resulting disassembled code to see
how it does software pipelining. The code uses a variant of the
branch instruction that did not exist for the R2000 and R3000
processors, so our textbook does not discuss it. Here's the
description:
BEQL (Branch On Equal Likely)
format: BEQL rs, rt, target
Compares the contents of registers rs and rt, and if these
are equal, branches to the specified target, with a delay of
one instruction. If the conditional branch is not taken,
the instruction in the delay slot is nullified.
This is different from the branch & jump instructions we've seen so
far, in that the instruction in the delay slot is executed only if the
branch is taken.
There is a corresponding BNEL (Branch on Not Equal Likely)
instruction, which treats the delay slot the same way as BEQL.
You might want to think about the reasons why instructions like these
would have been added to the MIPS instruction set.
Ari
Homework 2
Assembly codes generated by the C compiler and
the disassembler have different naming
conventions for register names.
C Compiler (gcc -S):
- integer registers: $0, $1, $2, ..., etc.
- floating point registers: $f0, $f1, $f2, ..., etc.
- floating point status register: (probably won't be genereated)
Disassembler (dis -h):
- integer registers: r1, r2, ..., etc.
- floating point registers: f1, f2, ..., etc.
- floating point status register: $31
Note that for the assembly code generated by the C compiler,
$31 is an integer register;
for the assembly code generated by the disassembler, $31 is a floating
point status register.
Bwolen (bwolen@cs.cmu.edu)
Homework 1
I made a mistake in the convergence condition in Problem 6. Instead of
- |t_{2n}^{'} - t_{n}^{'} | / t_{n}^{'} <= E
it should be
- |t_{2n}^{'} - 2t_{n}^{'} | / t_{2n}^{'} <= E, for t_{2n}^{'} > 0
where the notation t_{a}^{b} means t sub a sup b.
I also fixed it in the writeup in the course home directory:
/afs/cs/academic/class/15347-s97/public/asst/h1/h1.ps
Sorry about the error.
droh