SLIM Assembly Language Programming

MCS-178: Introduction to Computer Science II

Introduction

For this project, you will do some SLIM assembly language programming exercises from chapter 11 of our book. 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 will work on this project individually. However, feel free to ask your neighbor for help when you are getting started.

Mechanics

You will run SLIME as a Java applet directly from your web browser, either by clicking on the link in this project assignment, or by navigating to it from the web site of Concrete Abstractions supporting materials.

SLIME has a text area for entering your program and a load button that loads the program into the instruction memory and pops up additional windows for interacting with the simulated SLIM. To include your program in your project report, and save it for later use, you can use the Copy and Paste features to copy it from the web browser to some editor. Conversely, if you edit your program using a text editor, you can then just Copy it and Paste it into the SLIME program text area in the web browser.

The SLIME web page also contains links to several example programs from the book. You can Copy and Paste any of these programs into SLIME's text area in order to try it out.

As with most activities involving the mouse, this is easier shown than described. Once in project, your lab instructor (or a neighbor) will help to get you past these hurdles.

Getting acquainted

Load in each of the example programs count-to-ten and write-larger and then try running them. In addition to running them at full speed with Start, be sure to Step through them in order to see how the registers change.

Programming exercises

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. The exercises you should do are as follows:
  1. (Warm up) Exercise 11.2 on page 345. The code for this warm-up exercise should be included as an addendum to your project report, since it's obviously tangential to the rest of the assignment.
  2. Exercise 11.4 on page 351. The program in section 3.2 which performs exponentiation uses power-product:
    (define power
      (lambda (b e)
        (power-product 1 b e)))
    
    (define power-product
      (lambda (a b e)     ; returns a times b to the e power
        (if (= e 0)
            a
            (power-product (* a b) b (- e 1)))))
    

    Your program should read in only the base and exponent from the user, and should itself provide the starting value of 1 for a. 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 232. Feel free to ignore the overflows in this problem and also in the remaining problems.

  3. Exercise 11.5 on pages 351-352.
  4. Exercise 11.10 on pages 361. The recursive power procedure is
    (define power
      (lambda (base exponent)
        (if (= exponent 0)
            1
            (* base
               (power base (- exponent 1))))))
    

Postlab

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 Scheme and SLIM, but ignorant of specifically what you did.

Since the coding tasks are simple, the writeup describing the code will be short. In documenting your code, two 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 powers of 2, and test your program with several such exponents (e.g., 2, 4, 8, 16, and 32). All experimental results should be presented in a single table or one or more graphs.

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 experiments, make sure that you place the results in the same table so the reader can easily compare the numbers.

In presenting numerical data in a graph, be sure you choose appropriate axes. If you are predicting logarithmic or exponential running time, use semi-log paper to plot your results. An exponential such as cn when plotted on semi-log paper (with the y-axis logarithmic) looks like a straight line, where the slope of the line depends on the base of the exponent c. When logarithmic data like logb(n) is plotted with the x-axis on a logarithmic scale, the data appears straight. Lastly, to confirm that your data is a polynomial like n^c, use log-log paper, and see if the data appears on a line; the slope depends on the exponent c.

The gradesheet for the project is available in PostScript or PDF format. (If you print a copy out, you can staple it to the front of your project report to save paper.)

If you have more time

You are likely to learn more if you do either or both of the following optional activities. (You can do them in either order.)

Additional programming: The following is another recursive exponentiation procedure, more efficient than the one given above for exercise 11.10.

(define power
  (lambda (b e)
    (cond ((= e 0) 1)
    	  ((even? e) (square (power b (/ e 2))))
	  (else (* b (power b (- e 1)))))))
Translate this into SLIM assembly language. As with exercise 11.5, you can make analysis of this program easier by limiting yourself to exponents that are powers of two.

Additional analysis: In the postlab section, we suggested making measurements with exponents of 2, 4, 8, 16, and 32, all of which are powers of two. If you use exponents that aren't powers of two, then the analysis of the program from exercise 11.5 becomes more interesting. Suppose you write a number n in binary; for example 13 would be written as 1101 because it is 1*23 + 1*22 + 0*21 + 1*20, i.e., 8+4+1. Let a(n) be the number of zeros in this binary numeral (without any extra leading zeros tacked on at the left end), so that for example a(13)=1, and let b(n) be the number of ones in the binary numeral, so for example b(13)=3. Can you make a predication regarding how the number of instructions executed by the program from exercise 11.5 can be computed as a function of a(n) and b(n), where n is the exponent? Try experimentally verifying your prediction. The same issues also apply to the additional exponentiation program from the preceding optional activity. If you wrote that program, you can analyze it the same way and check your prediction for it as well.