# CS代考程序代写 Java assembly mips Lab 5: Functions and Graphics

Lab 5: Functions and Graphics
Due Friday March 12, 2021, 11:59 PM (Late hours cannot be used)
Minimum Submission Requirements
• Ensure that your Lab5 folder contains the following files (note the capitalization convention):
• Lab5.asm
• It is ok if you also have lab5_w21_test.asm, but we will not require or check it.
• Commit and push your repository
• Complete the Google Form with the correct commit ID of your final submission
Lab Objective
In this lab, you will implement functions that perform some primitive graphics operations on a small simulated display. These functions will allow users to change the background color of the display, and “draw” horizontal and vertical lines on the display. To simulate a display, we’ll be using the memory-mapped bitmap graphics display tool included with MARS.
To do this you will utilize:
• Arrays
• Memory-mapped Input/Output (IO)
• Subroutines (a.k.a. Functions or Procedures)
• Macros

Color and Computers
A pixel is commonly represented as a triplet of uint8s (i.e. unsigned 8-bit integers ranging from 0-255) specifying the intensity of red, green, and blue. Together this totals to 24 bits (i.e. 3 bytes) per pixel. Often this triplet is written in hex notation.
E.g. in this system, white = (255, 255, 255) = #ffffff, black = (0, 0, 0) = #000000, red = (255, 0, 0), yellow = (255, 255, 0), and (128, 64, 32) = #804020 is a brownish color. Here’s a tool you can play with to help you understand.
Often an extra 8-bits is used for a transparency channel, making the total 32 bits (= 4 bytes). We won’t use the notion of transparency here, but we will use this 4*8=32-bit standard (leaving the most significant 8 bits as 0). I.e. in this assignment, white = #00ffffff, black = #00000000, red = #00ff0000, and yellow = #00ffff00.
In our simple simulation, our display is equivalent to an uncompressed 128×128 32-bit “true color” image. To store (128 x 128 =) 16384 pixels, each being 4 bytes, takes 16384 x 4 = 65536 bytes. Note that 65536 = 2^16 = 16^4 = 0x10000. Our image will be stored in a memory segment spanning 65536 bytes, starting at memory address 0xffff0000 and taking up the remainder of the memory in our 32-bit address space.
Lab Preparation
• Familiarize yourself with RGB colors (e.g. make sure you understand the basic ideas explained in the above note on “Color and Computers”). You might also consider reading some background on Raster graphics.

• Introduction To MIPS Assembly Language Programming chapters 5, 6; sections 8.1, 8.2
• Macros
• Procedures watch videos 2.7 – 2.12
• Functions watch video tutorials 15 – 18
Specification
You will need to implement a set of specific subroutines indicated in these lab instructions. You are required to start with the skeleton code provided (lab5_w21_template.asm) and may not change the function names or arguments at all. Please rename the file to Lab5.asm and start with it. To receive any credit for your subroutines, Lab5.asm must assemble both on its own and with the test file. On its own, the template file shouldn’t print or draw anything — it is just a set of subroutines.
A test file (lab5_w21_test.asm) tests each one of your subroutines and includes (at the very end) your subroutines from Lab5.asm (based on the above template file). You should modify the test to include Lab5.asm instead of lab5_w21_template.asm. Don’t modify the test file — we will not use your test file during grading, we will use a similar but not identical test file of our own. Our test file will call your functions and macros. That’s why it’s so important your functions and macros follow the specifications given. In order for your subroutines to function properly, you must use the instructions JAL and JR to enter and exit subroutines. You must save and restore registers as required in MIPS. Our test file will look very much like this one, so you should ensure that your functions work with it!
Bitmap Display Tool
To visualize what you’re doing, you can use the bitmap display tool (Tools->Bitmap Display).

Functionality
The functionality of your program will support the following:
• All pixels should be in the range x in [0,128) and y in [0,128) (the parenthesis means not including 128).
• Pixels start from (0,0) in the upper left to (127,127) in the lower right.
• Pixel values are referenced in a single word using the upper and lower half of the word. So, for example, 0x00XX00YY) where XX and YY can be 0x00 to 0x7F.
• All colors should be RGB using a single 32-bit word where the top byte is zero. So, for example, 0x00RRGGBB where RR, GG, and BB can be 0x00 to 0xFF.
• All functions (subroutines) and macros described below. Note: signatures for each are included in the template.
Macro Descriptions
You are required to implement and use the three following macro definitions. Make sure not to alter their signatures as provided in the template as they may be called by a grading script. You may use additional macros if you like.

Subroutine Descriptions
These subroutines should be in the Lab5.asm file. You may use additional functions if you like. Again, these procedures will be called by the grading script, so make sure not to alter their signatures. Please only use registers beginning with \$t, \$a, and \$v when implementing these functions (except draw_crosshair, which should only make use of s, a, and v registers). Otherwise, our grading script may not work.

clear_bitmap, draw_pixel, get_pixel, draw_horizontal_line, draw_vertical_line, and draw_crosshair.

A Note on Debugging
Note that if you need to add print statements to lab5.asm for debugging purposes, make sure to remove them before submitting as otherwise they will interfere with our grading scripts.

Test Output
The test output for this lab is visual and requires you to use the MARS Bitmap Display tool (in Mars select Bitmap Display from the Tools menu). You should modify the settings of the bitmap display to be 128 x 128 pixels and to have a base address of the memory map (0xffff_0000) as shown here:

Press “Connect to MIPS” to use this in your program.

The bitmap display is a grid of 128 x 128 pixels that displays a color based off the value written to the address corresponding to that pixel. In the example above, you can see how the coordinates of the pixel relate to the array in memory for a 4 x 4 pixel bitmap. For example if you wanted to color the pixel at row 2, column 3 (i.e. at 0x00030002 ~ (3,2)) you would take the base address of the of the first pixel and offset that by +11 which is (2 * row_size) + 3 to locate the correct pixel to color.
We will be grading your solution by dumping the memory-mapped IO segment as hexadecimal ASCII and comparing with the correct results. You will miss all the points if you do not use the above size and base address configuration! In addition, your Lab5.asm should not display any text using syscalls as this will interfere with the grading output. If you want, you can also display the memory-mapped segment using a command line argument like this:

java -jar Mars4_5.jar nc 0xffff0000-0xfffffffc lab5_w21_test.asm

Sample Input/Outputs
When you’re finished, the bitmap will look like this (not including the gray outer border):

You are expected to read through and understand how the provided lab5_w21_test.asm file works. The test file will call the subroutines in your lab5.asm file and print to the console your results as well as the expected results. This is what the output of your completed lab should look like:

This output of the tests are available in this hex dump if you wish to compare. You can compare files online using a “diff” utility like Diffchecker or the bash “diff” command.
If your bitmap is correct, you should be able to make an exact copy of the hex dump using
java -jar Mars4_5.jar lab5_w21_test.asm 0xffff0000-0xfffffffC > my_output.hex
For full credit, your output should match ours exactly.
Automation
Note that part of our grading script is automated, so it is imperative that your program’s output matches the specification exactly. Output that deviates from the spec will cause point deduction.
You should not use a label called “main” anywhere in Lab5.asm. If you do, it will fail to work with our test cases and your assignment will not be graded.
Files
You do not need to include lab5_w21_test.asm in your repo, but you may if you like. We will be using our own test script, similar to the one you’re given, just with different xy-coords and colors.
Lab5.asm
This file contains your pseudocode and assembly code for all of the functions and macros and should be the only file you edit (except perhaps for debugging purposes). Follow the code documentation guidelines here. By itself, this file should not actually do anything but define the functions.
This file must be a plain text (.txt) file. It should contain your first and last name (as it appears on Canvas) and your CruzID. Instructions for the README can be found here.
Syscalls
You may use syscalls in the lab5_w21_test.asm file, but you should not use any syscalls in Lab5.asm. We inserted an exit syscall in the template to prevent it from running on its own and you can leave that there, but do not add any more.
Other Requirements
Turn Off Delayed Branching
From the settings menu, make sure Delayed branching is unchecked
Checking this option will insert a “delay slot” which makes the next instruction after a branch execute, no matter the outcome of the branch. To avoid having your program behave in unpredictable ways, make sure Delayed branching is turned off. In addition, add a NOP instruction after each branch instruction. The NOP instruction guarantees that your program will function properly even if you forgot to turn off delayed branching. For example:
LI \$t1 2  LOOP: NOP  ADDI \$t0 \$t0 1  BLT \$t0 \$t1 LOOP  NOP # nop added after the branch instruction  ADD \$t3 \$t5 \$t6