SLIM Assembly Language Programming

Start: 9/5/2019
Due: 9/18/2019, by the beginning of class
Collaboration: individual
Important Link: SLIME.jar, gradesheet


For this project, you will do some SLIM assembly language programming exercises from chapter 11 of Concrete Abstractions. For certain of these exercises, you are asked to gather statistics from SLIME (SLIM Emulator) in order to determine the relative efficiency of various SLIM programs that solve the same problem. You will also have the opportunity to see how the execution of a SLIM program progresses (how the registers and memory change in contents, how the PC steps, etc.), because the SLIM simulator we will be using provides a visual display of the execution.

You should work on this project individually. However, feel free to ask your neighbor for help with the mechanics of setting up SLIME when you are getting started.


You should start by downloading SLIME.jar, which is the Java archive containing the runnable version of SLIME, the SLIM Emulator. We’ll assume that your default download directory is ~/Downloads.

To run SLIME, you will need to first open up a terminal window by clicking the Terminal application’s icon:

Terminal icon

Terminal icon

Then, you can type the following command into the terminal window after the command prompt $, pressing the return key at the end:

$ java -jar ~/Downloads/SLIME.jar

This should work, popping up the SLIME windows, provided you downloaded SLIME.jar into your ~/Downloads folder, which is the normal situation. Otherwise you may need to change that portion of the command. Ask for help if you need it.

The load button in SLIME loads the program into the instruction memory from a text file, so you will first need to use a separate text editor to write the program and save it out. Our lab machines have “sublime text” and “textwrangler” installed. You can either type in your program or (for initial testing) just paste in one of the example programs from the book, which are available for copying from these web pages

Getting acquainted

Load in and try running each of the example programs write-larger and count-to-ten. In addition to running them at full speed with Start, be sure to Step through them in order to see how the registers change. Before doing exercise 2 below, you should also load, run, and understand iterative-factorial.

Specific tasks

Note that the postlab section, below, asks you to analyze some instruction count data, so you will have to gather the data for that in lab as well as doing the programming (and testing and debugging). Specifically, for the various exponentiation programs, you should at least gather data using several exponents that are powers of two, such as 2, 4, 8, 16, and 32. Note that these are the exponents; the base you use is arbitrary, as it shouldn’t affect the number of steps in each computation. You could just as well compute \(3^2\), \(3^4\), \(3^8\), etc. as \(2^2\), \(2^4\), \(2^8\), etc. The exercises you should do are as follows:

  1. Exercise 11.2 on page 345. This is a warm up exercise, but you should hand the code in anyway.

  2. Exercise 11.4 on page 351. The program in section 3.2 which performs exponentiation uses a Scheme procedure called power-product. Instead of learning Scheme for this lab, you should use the following Python function as a model for your SLIM code:

    # Assume e is a nonnegative integer.
    def power(b, e):
        pow = 1
        while e > 0:
            pow = pow * b
            e = e - 1
        return pow

    Your program should read in the base and exponent from the user, compute the power, and write out the answer.

    Note that a large result such as power(3, 32) may result in an overflow, that is, a value that differs from the correct one by some multiple of \(2^{32}\). Feel free to ignore the overflows in this problem and also in the remaining problems. However, you should definitely check the correctness of your programs using some smaller values for which overflow won’t be an issue and where you know the correct answer. For example, if any one of your programs doesn’t tell you that \(3^2=9\), you need to fix it.

  3. Exercise 11.5 on pages 351–352. Instead of the Scheme code given there, use the following Python function as a model for your SLIM code:

    # Assume e is a nonnegative integer.
    def power(b, e):
        pow = 1
        while e > 0:
            if e % 2 == 0:
                b = b * b
                e = e / 2
                pow = pow * b
                e = e - 1
        return pow
    Notice that this program treats even and odd exponents differently. For your performance data, you’ll be using exponents such as 2, 4, and 8, but for testing your program’s correctness, you should also include at least one other exponent.
  4. Exercise 11.10 on pages 361. The Python version of the recursive power procedure you should use as a model for your SLIM code is:

    # Assume e is a nonnegative integer.
    def power(b, e):
        if e == 0:
            return 1
            return b * power(b, e - 1)

    The instructions for Exercise 11.10 say “Try not to save any more registers to the stack than are needed.” I would weaken that a bit: don’t save any register that isn’t used after being restored.

Your report

In addition to the programming are asked to do, you will need to write a report analyzing the instruction count data for your procedures. This report should be scientific in nature, and should deemphasize the process of writing code and focus on the analysis of the running time of each procedure. Your project report should also explain the final products to an audience generally knowledgeable about SLIM, but ignorant of specifically what you did.

Since the coding tasks are small, the writeup describing the code will be short. In documenting your code, three things help to document assembly code: (1) Add comments describing blocks of a few statements, rather than a comment for each and every statement. (2) Choose your register names carefully, and (if not obvious) add a comment stating what each one is. (3) Add a comment at the top of each version of power describing any pre-conditions for your procedure; does your code work for all integer values of the arguments, or only some?

You are asked to compare the efficiency of the three different assembly language versions of power in exercises 11.4, 11.5, and 11.10. First, looking at each program, predict how many instructions will get executed by each program as a function of the exponent. Then, verify your predictions experimentally. You’ll find that for 11.5, it’s quite challenging to find a formula for the number of instructions when the exponent is not a power of 2. That’s OK; give a formula that only works for exponents that are powers of 2 and test your program with several such exponents. (For example, your values for the exponent e might be 2, 4, 8, 16, and 32, which would result in \(\log_2 e\) having the evenly spaced values 1, 2, 3, 4, and 5.) All experimental results should be presented in a single table.

In your report, for each of the three exponentiation programs, be sure to (a) give a precise formula for the number of steps as a function of the exponent, (b) state your logic for why the formula should be the one you gave (i.e., by looking at your program), and (c) explain how your data matches or fails to match your formula (and, in the latter case, why?).

In presenting numerical data in a table, your presentation is important. If you are comparing the results of two or more experiments, make sure that you place the results in the same table so the reader can easily compare the numbers. Also, all numbers in a column should be positioned so that the decimal points are vertically aligned. (This rule applies even if the decimal point isn’t explicitly shown.)

Extra credit

You can earn 5 extra credit points by implementing this recursive definition of the choose function:

# Assume n and k are nonnegative integers, with 0 <= k <= n.
def choose(n, k):
    if k == 0 or k == n:
        return 1
        return choose(n - 1, k - 1) + choose(n - 1, k)

You do not need to do any analysis for this procedure; only write correct and reasonably documented code for it in SLIM.


We will use this gradesheet when grading your lab.


You should submit your project using Moodle. Most of you should already have previous the experience submitting projects on moodle. If you need help, ask one of us.

You should submit the following files, with the following recommended names:

  1. report.txt (or report.doc) - your written report as described above. The write-up needn’t be fancy (in a word-processing sense), but it should certainly contain the materials described above.
  2. task1.txt - your SLIM code for task 1
  3. task2.txt - your SLIM code for task 2
  4. task3.txt - your SLIM code for task 3
  5. task4.txt - your SLIM code for task 4
  6. bonus.txt (optional) - your SLIM code for the extra credit (if you do it)

All SLIM code (that is, those files ending in .txt) must be text files. Do not use microsoft word to write them. Write them using a text editor instead.