Project 1: SLIM Assembly Language Programming

Start: Tuesday 2/10; Due: Monday 2/23, by the beginning of class

---

Overview

For this project, you will do some SLIM assembly language programming exercises from chapter 11 of our book, Concrete Abstractions. For certain of these exercises, you are asked to gather statistics from the SLIM simulator 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 when you are getting started.

Mechanics

You should start by downloading SLIME.jar, which is the Java archive containing the runnable version of SLIME, the SLIM Emulator.

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

Then, you can type the following command into the terminal window, 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. I suggest you use the TextEdit application by clicking its icon:

Once you have TextEdit running, you should use the Format menu's Make Plain Text command because the SLIM program should be saved out without such "rich text" features as fonts and margins. Then 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

• count-to-ten
• write-larger
• iterative-factorial
• two-factorials
• double-factorial
• recursive-factorial

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 effect the number of steps in each computation. You could just as well compute 3², 3⁴, 3⁸, etc. as 2², 2⁴, 2⁸, etc. The exercises you should do are as follows:

1. (Warm up, hand in) Exercise 11.2 on page 345. The code for this warm-up exercise should be included as an addendum to your project report because it's tangential to the rest of the assignment.

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:

       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. You may assume that e is nonnegative.
   
   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³². 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²=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:

       def power(b, e):
           pow = 1
           while (e > 0):
               if ((e % 2) == 0):
                    b = b * b
                    e = e / 2
               else:
                    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:

       def power(b, e):
           if (e == 0):
               return 1
           else:
               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. (It is possible to be even a bit more thrifty, but there are good reasons not to, which I can explain if you care.)

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₂ 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:

    def choose(n, k):
        if (k == 0):
            return 1
        elif (k == n):
            return 1
        else:
            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.

Gradesheet

We will use this gradesheet when grading your lab.

Submission

You should submit your project using Moodle. Some of you may already have previous experiences submitting projects on Moodle. If you need a refresher, follow our step by step instruction on submitting code (start with the Section "Uploading Files: Method # 1", the previous Section will be useful when you start project 2). Please being sure to select the section 2015 s-mcs-178-001, which is your lecture section.

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

1. 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 did it)