MIPS汇编代写: CMPE012/L LAB 5: HEX TO DECIMAL CONVERSION

UNIVERSITY OF CALIFORNIA, SANTA CRUZ BOARD OF STUDIES IN COMPUTER ENGINEERING

CMPE012/L: COMPUTER SYSTEMS AND ASSEMBLY PROGRAMMING LAB 5: HEX TO DECIMAL CONVERSION

MINIMUM SUBMISSION REQUIREMENTS:

• Create a lab5 folder
• Lab5.asm in the lab5 folder
• README.txt in the lab5 folder
• Commit and Push your repo
• A Google form submitted with the Commit ID taken from your GITLAB web interface verifying

  that the above files are correctly named in their correct folders

• All of the above must be completed by the lab due date

  LAB OBJECTIVE:

  In this lab, you develop a more detailed understanding of how data is represented, stored, and manipulated at the processor level. You will need to traverse an array, convert between ASCII and binary numbers, convert a hexadecimal number to a native binary number, and convert the native binary number to an ASCII signed decimal number. You will also gain additional experience with the fundamentals of MIPS coding, such as looping and checking conditionals.

  LAB PREPARATION:

  Read this document in its entirety, carefully. Read Introduction to MIPS Assembly Language Programming by Charles Kann, chapters 1 and 9.

  LAB SPECIFICATIONS:

  In this lab, you will write a MIPS32 program that reads a program argument string from the user, repeats that string, translates the string into a binary integer (in two’s complement format), stores that signed integer into a specific register ($s0), converts the signed integer into an ASCII decimal representation which is printed before exiting cleanly.

  You will need to write your own pseudocode for this lab. Your pseudocode must be part of your lab submission (as a block comment). Your code must follow your pseudocode.

  As always, your code should be clean and readable. Refer to Lab4 to see the standard of readability we expect.

  In this lab, all input syscalls are FORBIDDEN (that is, any syscall whose description begins with “read”). Instead, the user input will be passed to the program using a “program argument” string. This string will be the ASCII sequence “0x” (zero followed by x) followed by a sequence of eight hexadecimal digits in ASCII (‘0” – “9” and “A”-“F”). All hex letters are capitalized only! The input is 8 hex characters, so it is within the range of a 32 bit two’s compliment representation.

  Syscall 1 (print integer) and Syscall 36 (print integer as unsigned) are also FORBIDDEN. Note: you may use them for debugging your code, but you will get no points if you use it ANYWHERE(even in comments!) in the code you turn in. Instead, your code must convert the binary 2SC integer in register $s0 into an ASCII representation of the signed decimal number and output it using Syscall 11 (print character) or Syscall 4 (print string).

© 2018, Computer Engineering Department, University of California Santa Cruz Version 1.2

The number, as a single 32-bit binary integer, must be stored in $s0 at the time the program exits. You can use other registers as you wish, but $s0 is reserved!

Two examples of the expected output are given below. Your code’s output format should match this output format exactly. Capitalization is required!:

Please note that part of our grading process is automated and any deviation from this format will cause our grading script to fail. You do not get partial credit when you do not follow the format requirements.

In general, we do not grade on efficiency, but we do expect your code to use loops where appropriate. For example, do not repeat nearly-identical blocks of code to check each bit or several bits. Instead, write one block of code and loop over it. Similarly, we do not expect the highest performance code. Make sure your code is reasonable and produces the correct output in a reasonable run-time.

LAB STRATEGY:

This lab can be divided into four main parts:

1. Read program argument string
2. Convert the program argument to a binary integer in $s0.
3. Convert the value in $s0 as a 2SC number to an ASCII decimal number.
4. Print the correct signed ASCII decimal number before exiting cleanly.

We strongly recommend that you attack all of these steps in parallel. If you get stuck on part 1 (you probably will), then work on part 2 and return to part 1 later. One possible strategy is to write four

separate files, each one of which solves one part. Make sure to recombine them into Lab5.asm before turning it in.

READING PROGRAM ARGUMENTS:

In this lab, all input syscalls are forbidden. Instead, we will use “program arguments” to read user input. To introduce a program argument to your code, first use the MARS toolbar to turn on program arguments (Settings -> check “Program Arguments provided to MIPS program”). If you do this and then assemble your code, a white text field will appear at the top of your “Text Segment” window. This is where you enter a program argument.

To see how it works, press “assemble,” enter a string, and then advance your code by a single step. Notice that the $a0 and $a1 registers change. $a0 contains a small number, 1 (indicating that you passed one string into the program). $a1 contains an address. This address is a location in stack memory, it is the beginning of an array called the “program arguments pointer table.” To view that array, use the drop- down box in the “Data Segment” window and select “current $sp.” Find it. Currently, the table should contain exactly one element. That element is another address. It should be very nearby, and is the address of the program argument string.

To summarize: At time of startup, $a1 contains the address of a location in data memory, which in turn contains the address of your string, also stored in data memory.

Follow this method in your program to find the addresses and DO NOT hard code the address of your input. This information is passed “on the stack” and if the stack location changed, your program would break otherwise.

Be sure you understand how this works!

CONVERTING AN ASCII STRING TO A BINARY INTEGER:

Your program argument is stored as an ASCII string. You will need to handle each character of this string individually, and iterate over the string to combine all the information of the whole string into a 32-bit binary integer. This integer must be stored in $s0, and remain there for the rest of your code.

Each character of this string is an ASCII representation of a hexadecimal digit (“0” to “9” or “A” to “F” capitalized only). You will first need to convert each digit from ASCII representation into a binary integer (so, for example, you must turn “5” into 0b0101). Kann provides a useful description of the ASCII table that will help you find a procedure for this conversion.

You will need to use each successive digit of the input string to update the value stored in $s0. Think carefully about how to combine your current value and the next digit to find the next value. For example, if your “5” in hex is followed by a “3” (in hex), what steps are required to combine 0b0101 with 0b0011 to yield 0b1010011 (83 in decimal)?

CONVERTING FROM TWO’S COMPLIMENT:

If the most significant bit of your resultant number in $s0 is set, you have a negative number. You will need to take the two’s complement of the value in $s0 before you print it to find the magnitude. There are several ways to accomplish this in MIPS.

PRINTING IN DECIMAL:

Though MARS provides “print integer” and “print integer as unsigned” syscalls, you will receive zero points on this section if you use it. Instead, you must convert $s0 to a decimal string first. One convenient way is to use Binary Coded Decimal (BCD) which represents each decimal value as a 4-bit value. Several combinations of the 4-bits are not valid. Once you have the BCD value, you can easily convert to ASCII using the opposite of the technique when you converted from ASCII.

PSEUDOCODE:

The code that this lab requires is too complex to attempt without a plan. You will need pseudocode to guide you as you write (and to guide our staff as we help you debug your work). BEFORE you begin writing your complete program, write the pseudocode for your program.

As you code, you may find that your pseudocode was incorrect, or did not include enough detail to be useful. If you find that your code is diverging from your pseudocode, take the time to update your pseudocode! Pseudocode is a crucial tool for understanding and navigating your code, and it is rude to the staff to ask them to help you if you cannot provide that tool.

This must reflect your code accurately.

LAB WRITEUP:

Insert your pseudocode that accurately reflects the structure of your code as a block comment at the top of your Lab5.asm file.

Please use our README.txt template on Canvas to make grading easier. Be sure your write-up (in the README.txt file) contains:

• Appropriate headers
• Describe what you learned, what was surprising, what worked well and what did not
• Answer the following questions:

  1. How many representations of 0 are there in your input number?
  2. What is the largest input value (in decimal) that your program supports?
  3. What is the smallest (most negative) input value (in decimal) that your program supports?
  4. What is the difference between signed and unsigned arithmetic in MIPS (add vs addu, mult vs

  multu)? Which type did you use? What were the advantages or disadvantages of this choice?
  5. Consider how you might write a binary-to-decimal converter, in which the user inputs a string of ASCII “0”s and “1”s and your code prints an equivalent decimal string. How would you write your

  code?

  To alleviate file format issues we want lab reports in plain text. Feel free to use a word processor to type it up but please ensure that your README.txt is a plain text file and CHECK IT ON GITLAB to make sure it is readable.

  BUMPS AND ROAD HAZARDS:

  This lab is not easy. Make sure to start it early.

  This lab requires understanding how strings and values are stored at the bit level. It also requires an understanding of the relationship between addresses and memory. If the concepts in this lab are unclear to you, make sure you understand them before attempting to write long pieces of code. Do small experiments first.

  As usual, you will find that the MARS debugging tools are essential. Use breakpoints and step-throughs, and make sure you understand what the “Registers” pane and the “Data Segment” window are telling you. Make sure that you read the error messages that MARS gives you. They are relevant.