Hello, dear friend, you can consult us at any time if you have any questions, add  WeChat:  zz-x2580

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

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.

Please pay close attention to these guidelines:

1. Reasonable and consistent indentation is still required. Your editor should help. Convention is to indent

all instructions by one “tab”, to not indent labels, and to align per-line comments starting at the same

column. Our examples are generally formatted this way.

2. Your code must have a comment at the beginning with your name, university ID number, and UMD

Directory ID (i.e., your username on Grace).

3. Your code must be thoroughly commented. Assembly language can easily become unreadable without

proper documentation, so it is absolutely necessary that you comment your code.

4. Use appropriate whitespace, especially between blocks of instructions that are performing different

tasks.

5. There should be no need for global variables. Using global variables for format strings (e.g., .asciz ”%d”)

is fine.

6. Obey the callee-save and caller-save conventions; you may not clobber registers that the C driver does

not expect you to clobber.

7. Your entire assembly code needs to be commented. You will lose significant points if more than 25% of

the lines having instructions are uncommented.

8. Make sure you leave at least one space between an instruction and the semicolon that starts a comment.

You need comments next to the instructions (on the same line).

9. You can use either the strlen (from the C string library) or your own (from the assembly exercise). You

don’t need to include any files to use the C string library; you can call strlen as its linked using avr-gcc.

10. Even if you are not planning to implement a function for a while, you need to provide an empty shell

(i.e., name and ret instruction) that will allow the submit server to build your code.

11. Commonly seen Assembly mistakes can be found at:

1. For your code to build in the submit server, you need to add to each .S file a shell of the function you

need to implement (similar to the provided fibonacci.S file).

2. Feel free to use code examples provided in lecture.

3. Submit often so you have a copy of your code in the submit server.

4. Adding your own targets to the Makefile is fine, but do not modify the ones provided.

6 Submission

Submit as usual.

6.1 Deliverables

The only files we will grade are your .S source files.

3

7 Academic Integrity

Please see the syllabus for project rules and academic integrity information. All programming assignments in

this course are to be written individually (unless explicitly indicated otherwise in a written project handout).

Cooperation between students is a violation of the Code of Academic Integrity.