CMSC216- Project #5 Solved

1          Overview
In this project you will write AVR assembly code that corresponds to C code provided. There are two deadlines associated with this project:

 Your code must pass the first two public tests (PUBLIC 1, PUBLIC 2) and two release tests (RELEASE 1, RELEASE 2) in the submit server. That is the only requirement for this deadline. Unlike previous projects, this first deadline is worth 1.5% of your course grade (NOT .5%). Notice you can still submit late for this part.
Final deadline for the project. Notice you can still submit late (as usual).
2          The Makefile
In the code distribution you’ll see two .c files for each function you need write; you’ll fill in the third (a .S file).

c - A reference C implementation of what you should write.
c - A main() that invokes your code (or the reference, depending on the Makefile) with various inputs to print the output.
S - Here is where you will define the function that in AVR assembly mimics the reference code.
The Makefile has several rules. For example, for palindrome.S:

make palindrome_s       /* builds executable */ make palindrome_s.run /* runs the program using simulator */ make palindrome_s.gdb /* runs the debugger */

Although the base name of the assembly file is palindrome, we use palindrom s. You can also see the expected output for a test based on the reference code (C code). For example, for palindrome.S:

make palindrome_r.run /* runs the reference code (C code) */

Notice the use of r. By the way, the driver code contains the public tests.

3          Specifications
For each C routine, create an assembly program that produces the same output, given identical input. Your primary goal should be to produce a working version of each program. Your secondary goal is to make it no more complicated than it needs to be.

The input is provided by main(); you will not be expected to read integers or halt (cli/sleep) at the end of your functions. You need only implement the routine, and the _driver.c will invoke the routine as needed.

3.1        Palindrome
Ask if it seems unclear. Palindromes are words or phrases that are the same forward as backwards, the C code shows an example of how to do it.

You may optimize the code, since array subscript operations are not straightforward. (You need to get to a pointer to read from memory, the pointer is in X, Y, or Z, and although you can access at a constant offset from a pointer (“LDD Rd, Z+q”) there is no single AVR instruction for array subscripting (variable pointer + variable offset).)

3.2        Fibonacci
Given n as a (uint16_t) parameter, it returns the nth Fibonacci number. This routine must be implemented in a recursive fashion otherwise you will lose most of the credit.

3.3        Integer Square Root
Compute the square root of an integer, using the bitwise algorithm at https://en.wikipedia.org/wiki/ Integer_square_root.

You will need the logical shift instructions. To shift left by one, “lsl r24”. To shift left by two, repeat the instruction. Same for shifting right.

3.4        Reverse Prefix Sum
Transform an array by adding the value at an index to the sum of the remainder of the array. Return the sum. The return value may be a 16-bit integer, but the array is of 8-bit integers. (Do not concern yourself with behavior on overflow, just assume it will not happen.) The reverse prefix sum routine must be implemented in a recursive fashion otherwise you will lose most of the credit.

3.5        Rules
You may refer as much as you like to the output of avr-gcc -S. You may run “make isqrt_reference.s” for example. We expect you to use this information only to help with individual fragments, for example, to learn how to add two words together, call shift instructions, find which instructions to execute, etc. We expect you to avoid copying any code from the compiler output.
(Restated...) You are expected to write the assembly code; this is preparation for exam questions. You can look at the compiler’s output if you need inspiration, but turning in something conspicuously similar to the compiler’s output will lose (at least) style points. The output of the compiler is inefficient, uncommented, and has an identifiable style that is more complicated than what humans would write.
Notice that you don’t need to look at the compiler’s output in order to implement the project.

Don’t change the C code.
You don’t have to worry about the maximum length of 80 for a line of code. (You might write long comments.)
Your comments should be descriptive of the intent, not of the action. A comment per line after a semicolon descriptive of what is happening is necessary. (I.e., “stash n for later use” is an ok comment. “move r24 into r20” is not.) A description of the variable that each register represents is useful.
Obey the callee-save and caller-save conventions; you must not clobber registers that the C driver does not expect you to clobber. If you have close control over only calling functions that you have personally written, you may be able to get away with skipping saving some caller-save registers; do not take advantage of this feature.