Assignment 3: SCRAMing and MIPSing
Out on:
February 11, 2008
Due by:
February 18, 2008, noon (before lecture)
Collaboration:
None
Grading:
Packaging 10%, Style 10%, Functionality 80%
Overview
The third assignment covers material on the SCRAM as well as some MIPS programming, stuff we covered in the second and third week. Note that you now have to submit archives, not just simple text files anymore! Read the new rules carefully...
Problem 1: SCRAM
Give the SCRAM micro code in register transfer language (RTL)
for the STA, STI, SUB, and JMZ instructions.
Sketch the circuits inside the control unit of our SCRAM that
implement those instructions.
The (longish) answer for this problem should go into your
README file.
Problem 2: Odding Some Evens
Write a MIPS program odd_even.s that reads an
integer from the user and determines whether the integer is
odd or even.
It prints That's odd! for odd integers and
We're even! for even integers.
Try to find the shortest, most efficient way to determine
"oddness" or "evenness".
If you need the div instruction, you have not
found it yet.
Problem 3: Integer Averaging
Write a MIPS program on_average.s that reads a
sequence of positive integers from the user, stopping at the
first negative one.
Your program should print the integer average of all positive
integers that were entered.
Be very careful about the corner cases for this
one, an error message might be needed at some point...
Deliverables
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
cs102-assign-3-login.tar.gz
with login replaced by your Unix login name
on ugradx.cs.jhu.edu
(so I would use cs120-assign-3-phf.tar.gz).
The tarball should contain no derived files whatsoever
(i.e. no executable files),
but allow building all derived files.
Include a README file (a plain Unix text file) that
contains your answers to written problems, briefly explains what
your programs do, and has any other notes you want us to check
out before grading.
Grading
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, suitable documentation, etc.
Simple, clean, readable code is what you should be aiming for.
Performance refers to how fast your program can
produce the required results compared to other submissions.
Design refers to proper modularization and the
proper choice of algorithms and data structures.
Functionality refers to your programs being
able to do what they should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file.
If your programs cannot be built/run you will get no points whatsoever. If your programs fail miserably even once, i.e. terminate with an exception of any kind or dump core, we will take off 10%. Finally, make sure to include your name and email address in every file you turn in!
Bonus Problem
If you really want to impress us, try the following. Explain in your own words why the good old 6502 processor has "undocumented opcodes"? How did they get in there? How did people find out about them? Was it (or is it) a good idea to use any of them? Note that we won't give you extra points for this, but we'll give you extra kudos. :-)
