CMSC 216 Project
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:
? Tue, Jul 21, 11:30 PM - Your code must pass the first two public tests (PUBLIC 1, PUBLIC 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.
? Thu, Jul 23, 11:30 PM - 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).
? x_reference.c - A reference C implementation of what you should write.
? x_driver.c - A main() that invokes your code (or the reference, depending on the Makefile) with various
inputs to print the output.
? x.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).)
1
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
1. 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.
2. (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.
3. Don’t change the C code.
4. You don’t have to worry about the maximum length of 80 for a line of code. (You might write long
comments.)
5. 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.
6. 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.
7. Do not use rcall to call functions.
4 Grading Criteria
Your project grade will be determined by the following:
Results of public tests 50%
Results of secret tests 38%
Code style grading (verify by TA) 12%
2
4.1 Style grading
For this project, some style guidelines are obviously different, as you are writing in assembly language, not C
