MCS-284 Lab 1: Elementary assembly programming

Due September 21, 2007

The goal of this lab is to get familiar with the xspim simulator, try out some of the simple programs we've been writing in class, and write and test a couple more programs of your own. In this lab, we'll steer clear of fancy things like recursion and other uses of memory; that's what the next lab is for.

I expect you to do this lab in teams of two, with one exception if we have an odd number of students. Please form your own team of two, or contact me if you want to work alone or as a team of three; you may not work alone or as a team of three without my approval. If you are having trouble finding a partner (but want to work in a team), see me.

Your lab write up can be short and sweet, but it should be English. Specific details I will expect to see are the two programs you are asked to write, a description of how you tested your program (and/or test data and results) from those two programs. Your program should include enough comments or formatting to make it easily readable. Make sure your testing is systematic and thorough. Thorough doesn't mean using large quantities of weird numbers that still only test the same cases; rather, it means using carefully chosen tests to ensure that all cases are covered and all likely bugs exposed, while still allowing the answers to easily be hand-checked.

You will do this lab on one of the Linux PCs in OHS 326. You will use xspim, as described in Appendix A of the book. To run it, you can just type xspim in a shell window. You can type your programs in and edit them using either emacs or the "Text Editor," both of which are found in the Applications sub-menu of the K menu. Let me know if you have troubles with this or other Linux/X-windows user interface stuff.

Your program should start with the label 

main:
This is because xspim automatically loads some "startup" code, which is what is run when you tell xspim to run the program. The startup code does a jal main instruction, transferring control to your code. Note that this is a subroutine call. Thus your code can end with jr $ra, returning control back to the startup code. If so, the startup code will then exit, using the exit system call (number 10). Alternatively, your program can do the exiting itself, by putting 10 in register $v0 and then executing a syscall instruction.

The xspim program displays register contents, data memory contents, and the addresses of instruction and data memory as hexidecimal (base 16) numerals instead of the decimal ones you are used to. (This uses a-f as additional digits with values 10-15, so that by having each digit of the numeral any of 0123456789abcdef it can be in the range from 0-15.)

If you want to convert any of these to decimal to help you understand what is going on, here is one easy way. Run Scheme (as in MCS-177 and 178) and then input the number, but starting with #x. For example if you evaluate #x1a, Scheme will return 26, showing that that hexidecimal 1a converts to decimal 26.

Start by stepping through simple programs, like one to add two numbers. This part of the lab is to make sure you are comfortable with SPIM.

Now you have two programs to write and test and debug (if necessary). You can do these in whichever order seems more natural for you.

  1. Do exercise A.6 from page A-83.

  2. Do exercise A.7 from page A-83. Do not add all three numbers and then subtract off the smallest, since that might fail if the addition of all three overflowed the range of numbers representable in 32 bits. However, you may none the less find it useful to think about identifying which one number is the smallest, rather than about identifying which two numbers are the largest.
Common pitfalls: The most common mistakes students make on this assignment are
  1. Students often assume that registers will have some specific value (e.g., 0) when the program starts running. In fact, the only registers you can count on to have well defined values when main is invoked are $sp, $ra, and $zero. Any other values you observe in xspim are just luck, and shouldn't be counted on.
  2. Students often don't take seriously enough the requirement that testing be thorough, that is, that it probe all cases that differ from one another in some qualitative way. This is a particular problem area with the second program. Think hard about this even before you write a single line of code. How many different cases are there?
  3. Don't forget to review the third paragraph of this assignment which discusses the brief writeup.