CS274: Computer Architecture - Introduction to MIPS Programming (100 Points)

Assignment Goals

The goals of this assignment are:
  1. To read, write, and execute a MIPS Assembly Language Program
  2. To gain familiarity with a MIPS simulator to run MIPS assembly language code

Background Reading and References

Please refer to the following readings and examples offering templates to help get you started:

The Assignment

The Flesch-Kincaid Reading Level is a measurement of the writing level of text. It calculates the recommended grade level for the reader of the text. The formula uses floating point vlues, but for simplicity, we’ll modify the formula to use integers instead for this lab:

\(gradeLevel \approx wps + 5 \times spw - 12\)

Where wps is the number of words per sentence, and spw is the number of syllables per word in the text. In this lab, you will write a MIPS assembly program to compute the Flesch-Kincaid Reading Level, given these values as inputs.

We’ll use integers today because integers and floating point values are represented differently under the hood, so, as you’ll soon learn, they use different instructions in the language to perform arithmetic on them!

What to Do

Writing Your Program

Begin by writing a blank MIPS assembly program:

.text
.globl main

Reading User Input

Begin by prompting the user to input integer values fomr wps and spw using a syscall. To perform the syscall that prints the prompt to the screen, set $v0 to 4 using the li instruction, set $a0 to your prompt label using the la instruction, and call syscall. In your .data section, you can declare your string variables. Be sure to add a \n to the end of your string to print a newline! This will look like the following:

        .data
msg:   .asciiz "Please enter the number of words per sentence:\n"

        .text
# what you had before!
li $v0, 4
la $a0, msg
syscall

Read in an integer using syscall, but this time merely set $v0 to 5. $v0 will contain the integer the user types in when finished. Repeat this process for each variable you wish to input: prompt the user, read an integer, and copy that integer into a register to save it (you can add $t0, $v0, $zero to copy $v0 into $t0, but be sure to use a different register for wps and spw).

Keep in mind that the register $v0 is overwritten by the user’s input when you type in an integer value, so you’ll need to reset $v0 before making the next syscall.

Computing the Formula

Use the R type instructions add, sub, and the pseudoinstruction mul (we will learn how MIPS processors multiply numbers later), calculate the grade level using the formula and the registers containing wps and spw.

Outputting the Result

To print an integer, invoke syscall with $v0 set to 1, and $a0 containing the value you wish to print. Print the grade level.

Summary

The general strategy is as follows:

  1. Perform a syscall number 4 to print a message prompting the user to input wps.
  2. Perform a syscall number 5 to read in an integer.
  3. Copy that value from $v0 to a temporary register that will represent the wps value.
  4. Perform a syscall number 4 to print a second message prompting the user to input spw.
  5. Perform a syscall number 5 to read in an integer.
  6. Copy that value from $v0 to another temporary register that will represent the spw value.
  7. Load your formula constants (the 12 and the 5 in the formula above) into temporary registers using li instructions.
  8. Using the add, sub, and mul instructions, compute the formula into a new temporary register. Be aware of order of operations!
  9. Copy your answer into the $a0 register, and perform a syscall number 1 to print an integer (the one stored in $a0). This will print your result.
  10. Perform a syscall number 10 to quit the program.
  11. In the .data section, create two strings to hold your prompt messages (including a \n character for each).

Memory Layout Sketch

As part of your readme, include a sketch of the memory layout of your MIPS program. Every MIPS program is laid out in memory according to a standard convention:

  • The text segment (your code – everything after .text) begins at address 0x00400000.
  • The static data segment (everything you declare after .data, including your .asciiz string literals) begins at address 0x10010000.
  • The heap (dynamically allocated memory) sits just above the static data and grows upward toward higher addresses.
  • The stack starts near 0x7FFFFFFC and grows downward toward lower addresses.

In your sketch, label where each of your labels lives: your main: label belongs in the text segment, and each of your prompt strings belongs in the data segment. Also label which segment each of the following points into: the stack pointer $sp (the stack) and the program counter PC (the text segment, at whichever instruction is currently executing).

Here is a fully worked example for a tiny “hello world” program whose code is at main: in the text segment and whose string is at msg: in the data segment:

        .data
msg:    .asciiz "Hello, world!\n"

        .text
        .globl main
main:   li $v0, 4
        la $a0, msg
        syscall
        li $v0, 10
        syscall

High addresses
0x7FFFFFFC  +----------------------------+  <-- $sp starts here
            |           Stack            |
            |   (grows DOWNWARD)  |      |
            |                     v      |
            |............................|
            |                            |
            |      (unused memory)       |
            |                            |
            |............................|
            |                     ^      |
            |   (grows UPWARD)    |      |
            |           Heap             |
            +----------------------------+
0x10010000  |     Static Data (.data)    |
            |  msg: "Hello, world!\n"    |  <-- msg is at 0x10010000
            |  (first .data label gets   |
            |   the first data address)  |
            +----------------------------+
            |                            |
0x00400024  |   main: li $v0, 4          |  <-- your code starts here*
            |         la $a0, msg        |  <-- PC points somewhere in
            |         syscall            |      this text segment as
            |         li $v0, 10         |      your program runs
            |         syscall            |
0x00400000  +--- Text Segment (.text) ---+
Low addresses

* SPIM places a few startup instructions at 0x00400000 before
  jumping to your main label, so main may begin at 0x00400024;
  in MARS, main may begin right at 0x00400000.

Notice that because msg: is the first (and only) label in the .data section, it is placed at the very start of the static data segment, 0x10010000. In your program, you have two prompt strings; the first begins at 0x10010000, and the second begins right after the first string’s characters (including its invisible terminating \0 byte).

You can verify these addresses in your MIPS simulator: look at the data segment and text segment displays (in JsSpim and QtSpim, these are shown as panes; in MARS, use the Data Segment window and the Text Segment window). Single-step your program and watch the PC and $sp registers to confirm which segments they point into.

Answer these questions in your readme along with your sketch:

What address does your first prompt string label get in the simulator, and why does la $a0, msg load exactly that value into $a0?

At what address does your second string begin? Explain how the length of the first string (don’t forget the \0 terminator!) determines this address.

This sketch and your answers are assessed as part of the Writeup and Submission portion of the rubric.

Design Questions to Help You Begin

Please answer the following questions in your README file before you begin writing your program.
  1. Step through the "Hello World" example assembly program in your MIPS Simulator. As you step from instruction to instruction, what registers and memory values change?

Submission

In your submission, please include answers to any questions asked on the assignment page, as well as the questions listed below, in your README file. If you wrote code as part of this assignment, please describe your design, approach, and implementation in a separate document prepared using a word processor or typesetting program such as LaTeX. This document should include specific instructions on how to build and run your code, and a description of each code module or function that you created suitable for re-use by a colleague. In your README, please include answers to the following questions:
  • Describe what you did, how you did it, what challenges you encountered, and how you solved them.
  • Please answer any questions found throughout the narrative of this assignment.
  • If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work?
  • Please identify any and all portions of your submission that were not originally written by you (for example, code originally written by your buddy, or anything taken or adapted from a non-classroom resource). It is always OK to use your textbook and instructor notes; however, you are certifying that any portions not designated as coming from an outside person or source are your own original work.
  • Approximately how many hours it took you to finish this assignment (I will not judge you for this at all...I am simply using it to gauge if the assignments are too easy or hard)?
  • Your overall impression of the assignment. Did you love it, hate it, or were you neutral? One word answers are fine, but if you have any suggestions for the future let me know.
  • Using the grading specifications on this page, discuss briefly the grade you would give yourself and why. Discuss each item in the grading specification.
  • Any other concerns that you have. For instance, if you have a bug that you were unable to solve but you made progress, write that here. The more you articulate the problem the more partial credit you will receive (it is fine to leave this blank).

Assignment Rubric

Description Pre-Emerging (< 50%) Beginning (50%) Progressing (85%) Proficient (100%)
Algorithm Implementation (60%) The algorithm fails on the test inputs due to major issues, or the program fails to compile and/or run The algorithm fails on the test inputs due to one or more minor issues The algorithm is implemented to solve the problem correctly according to given test inputs, but would fail if executed in a general case due to a minor issue or omission in the algorithm design or implementation A reasonable algorithm is implemented to solve the problem which correctly solves the problem according to the given test inputs, and would be reasonably expected to solve the problem in the general case
Code Quality and Documentation (30%) Code commenting and structure are absent, or code structure departs significantly from best practice, and/or the code departs significantly from the style guide Code commenting and structure is limited in ways that reduce the readability of the program, and/or there are minor departures from the style guide Code documentation is present that re-states the explicit code definitions, and/or code is written that mostly adheres to the style guide Code is documented at non-trivial points in a manner that enhances the readability of the program, and code is written according to the style guide
Writeup and Submission (10%) An incomplete submission is provided The program is submitted, but not according to the directions in one or more ways (for example, because it is lacking a readme writeup) The program is submitted according to the directions with a minor omission or correction needed, and with at least superficial responses to the bolded questions throughout The program is submitted according to the directions, including a readme writeup describing the solution, and thoughtful answers to the bolded questions throughout

Please refer to the Style Guide for code quality examples and guidelines.