SLIM Assembly Language Programming

MCS-178: Introduction to Computer Science II
Max Hailperin, Fall 2001

Due: October 8th, at the beginning of class

Introduction

For this lab, 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 versions of 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, the PC steps, etc.), because the SLIM simulator we will be using provides a visual display of the execution.

You will work on this lab 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 lab 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 lab report, and save it for later use, you can use the Copy and Paste features to copy it from the web browser to Applix (or some other editor, like emacs). Conversely, if you would rather edit your program in Applix (or some other 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 program text area in order to try it out.

As with most activities involving the mouse, this is easier shown than described. Once in lab, 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:

Exercise 11.2 on page 345.
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 2³². Feel free to ignore the overflows (also in the remaining problems).
Exercise 11.5 on pages 351-352.

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

As usual, write up a lab report that explains your final products to an audience generally knowledgeable about Scheme (and also SLIM for this lab), 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 necessary) add a comment stating what each one is.

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, try experimentally verifying your predictions. 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. Be sure that if you are comparing results of two experiments, that you place the results in the same table so the reader can easily compare the numbers.

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*2³ + 1*2² + 0*2¹ + 1*2⁰, 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.