Assignment 5: Some MIPS with SPIM!


The fifth assignment is all about hacking MIPS assembly code using the excellent SPIM simulator. Note that we’ll use “SPIM Version 8.0 of January 8, 2010” which is the default in Lubuntu! For some problems we give you a bunch of starter code on Piazza already, so for those all you have to do is fill in one or two subroutines in the way described below (and in the code itself, be sure to read it for all the gory details). Note that for all problems the MIPS conventions regarding register usage (arguments, results, caller-saved vs. callee-saved, etc.) are in effect! (The full MIPS calling conventions are not in effect though.)

Problem 1: Insertion Sort (40%)

Sorting is always a popular programming problem, and now it’s time to hack a sorting algorithm in MIPS assembly. Sadly this is going to be a little less exciting than it was for the 6502 because our MIPS simulator doesn’t have any cool graphics features.

Note that you don’t have a choice of sorting algorithm, you must implement insertion sort! Also note that the operation of swapping two array elements must also be a subroutine, and that subroutine should be called from within the sorting subroutine! Finally, please make sure that you access the array only through the subroutine’s parameters and not directly as a global!

Your job? Add the necessary subroutines to the file insertion.s of course!

Problem 2: Fibonacci: Iterative and Recursive (40%)

The starter code includes an iterative (iter_fact.s) as well as a recursive (recu_fact.s) implementation of the Factorial function complete with a simple driver program (actually there are two recursive ones, but you just have to pick one of them to follow). For this problem you’ll write analogous functions/programs to compute the n-th Fibonacci number instead. The Fibonacci numbers are defined by the following recurrence:

F(n) = F(n-1) + F(n-2)
F(1) = 1
F(0) = 0

Your driver program should read an integer from standard input and then print the corresponding Fibonacci number to standard output. You may reuse the driver program from the starter code if you want, it doesn’t require any changes. Please call your iterative Fibonacci program iter_fib.s, your recursive Fibonacci program should be called recu_fib.s.

Problem 3: Integer Square Root (20%)

For this last problem you’ll write a function (and driver program) that computes the integer square root of a 32-bit integer. The integer square root of a positive integer n is the greatest integer less than or equal to the (actual) square root of n.

Your driver program isqrt.s should read an integer from standard input and then print the corresponding integer square root to standard output. You may (once again) reuse the driver program from the previous problem.

Here’s the twist: Your function should be fast! There’s no easy measure for “fast” here other than the number of MIPS instructions you execute for a given input. So you want to make sure to run as few instructions as possible for computing the integer square root! Also you cannot use floating point MIPS instructions, everything has to be done with integer instructions!

Problem 4: The MIPS-y Truth (0%)

One nice thing about MIPS assembly and SPIM in particular is that the tools hide a lot of the complications of the actual CPU from assembly language programmers. However, knowing the full truth (and nothing but the truth) about your CPU is actually rather helpful for hacking good assembly code. So for this problem, we’ll leave behind all those cozy comforts you may already have become used to and deal with the “true MIPS” instead.

Your job? First read the delay.s code we provided for you carefully, then convert it to equivalent code (see the file itself for details!) that will run on the bare MIPS with identical results as the original code produced for the nice MIPS. Here is the output you want to get, without any errors and without fundamentally changing the program; for example, you’re not allowed to remove the memory references from the code even though there are more than enough registers available.

$ spim -bare -file delay.s
SPIM Version 8.0 of January 8, 2010
Copyright 1990-2010, James R. Larus.
All Rights Reserved.
See the file README for a full copyright notice.
Loaded: /usr/lib/spim/exceptions.s

Yes, this is indeed an optional problem. You are not required to do it. You might like it though…


Please follow the submission instructions as detailed on Piazza. Make sure that your tarball contains no derived files whatsoever (i.e. no executable files), but allows building all required derived files. Also, be sure to include a Makefile that sets the appropriate compiler flags and builds all programs by default. Include a plain text README file that briefly explains what your programs do and contains any other notes you want us to check out before grading; your answers to written problems should be in this file as well. Finally, make sure to include your name and email address in every file you turn in (well, in every file for which it makes sense to do so anyway)!


For reference, here is a short explanation of the grading criteria; some of the criteria don’t apply to all problems, and not all of the criteria are used on all assignments.

Packaging refers to the proper organization of the stuff you hand in, following both the guidelines for Deliverables above as well as the general submission instructions for assignments on Piazza.

Style refers to programming style, including things like consistent indentation, appropriate identifier names, useful comments, suitable documentation, etc. Simple, clean, readable code is what you should be aiming for. For C programs, make sure you follow the style guide posted on Piazza!

Design refers to proper modularization (functions, modules, etc.) and an appropriate choice of algorithms and data structures.

Performance refers to how fast/with how little memory your programs can produce the required results compared to other submissions.

Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous, ask for clarification! (It also refers to you simply doing the required work, which may not be programming alone.)

If your programs cannot be built you will get no points whatsoever. If your programs cannot be built without warnings using the required compiler options given on Piazza we will take off 10% (except if you document a very good reason). If your programs cannot be built using make we will take off 10%. If valgrind detects memory errors in your programs, we will take off 10%. If your programs fail miserably even once, i.e. terminate with an exception of any kind or dump core, we will take off 10% (for each such case).