Assignment 4: The MIPS Conspiracy
Out on:
February 18, 2008
Due by:
February 24, 2008, noon (before lecture)
Collaboration:
None
Grading:
Packaging 10%, Style 10%, Performance 10%, Functionality 70%
Overview
The fourth assignment concentrates on MIPS programming exclusively, stuff we covered in the third and fourth week. Note that we changed the grading criteria to include a score for performance. First and foremost you need to solve the problems correctly. However, after you have solved a problem, you should look back over it to see if there's a way to do it faster or using less memory or fewer registers. Without sacrificing readability of course.
Problem 1: Of Squares and Roots (20%)
Write a MIPS program square_root.s that
reads a positive integer from the user and prints the
integer square root of that integer.
For example, the integer square root of 12 is 3, since
3*3 is 9 but 4*4 is 16 already (the real square
root of 12 would be 3.46410162... but that's
not an integer).
You are free to choose whatever algorithm you think is appropriate. However I would recommend that you simply keep squaring numbers starting from 1 until you either hit the number whose root we want (bingo!) or exceed it (in which case it was the candidate from the previous iteration).
Of course the details are up to you, so feel free to try something different like adapting Newton's Method or doing a variation of binary search. Those are going to be harder of course...
Problem 2: Binary Illusions (20%)
Write a MIPS program print_binary.s that
reads an integer from the user and prints out its
binary representation.
For example, if the user enters 45, your
program should print 101101; if the user
enters 8, your program should print
1000; and so on.
You should write a function print_binary that
gets the integer to print in $a0; reading the
integer should be done in main though.
Problem 3: Bubbling Around (60%)
Your final task for this assignment is to complete the
program you started in lab this week.
Your program should be called bubble_sort.s
and it should be structured as follows:
-
Integrate the random number generator function
randomwe provide here. Note that this function does not take any arguments but returns the next random number in$v0. -
Write a function
bubblethat uses the Bubble Sort algorithm from lab to sort an array. This function should get the address of the array to sort in$a0and the length of the array in$a1; it does not return anything. -
Write a
mainfunction that uses therandomfunction to fill an array of 256 words, prints the array, uses thebubblefunction to sort the array, and finally prints the array again.
If you think you could use another function to your advantage, feel free to introduce one. If you are calling functions from other functions, make sure you handle the stack correctly; you probably won't need this though...
Deliverables
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
cs102-assign-4-login.tar.gz
with login replaced by your Unix login name
on ugradx.cs.jhu.edu
(so I would use cs120-assign-4-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.
Write a MIPS program guess_this.s that plays
the (infamous) "Guess the Number" game.
The "player" thinks of a number from 1 to 100, and your
program "guesses" that number by asking a few questions:
Think of a number between 1 and 100. Hit return when you're ready. Is your number between 1 and 50? n Is your number between 50 and 75? y Is your number between 50 and 62? n Is your number between 63 and 69? ...
And so on, eventually you print the number the "player" thought of (assume he or she answers accurately of course). Actually, there are not too many questions left, but you're writing this, not me. Note that we won't give you extra points for this, but we'll give you extra kudos. :-)
