Instructions

Documentation and structuring should be incorporated into programs from the beginning. Neither instructors nor teaching assistants will help with incomprehensible programs.

I highly recommend that you find an account on a Unix (or Mac OSX) machine or that you install Cygwin on your Windows machine.

The instructional lab machines should have OCaml, Ruby and Python pre-installed.

Automatic Grading

• Submit your assignment ZIP files via this course website.
• Programming assignments are due at 11:50pm on the date listed in the course schedule.
• Note that your final grade for an assignment is based not only on your performance on the automated test cases, but also on your coding, README and software engineering (see below).

Language Guides

• Randal E. Bryant and David R. O'Hallaron's x86-64 Machine Level Proramming
• Wikibook's X86 Assembly/GAS Syntax
• Stack Overflow on Assembly Debugging with GDB
• GDB's Manual on Inspecting Registers

Cool Assembly Language. The definitive source for the assembly language definition as well as the machine model is the Cool Reference Manual.

CA1: Dead Code Elimination

• Project Handout
• Grading (out of 50)
  • 41 points - for autograder tests
    • Each missed test (i.e., each instance of the word "FAILED" in the report) removes points, to a minimum of 0/41, even if there are more tests than total points.
  • 4 points - for a clear description in your README
    • 4 - thorough discussion of design decisions (including language comparisons) and choice of test cases; a few paragraphs of coherent English sentences should be fine
    • 2 - vague or hard to understand; omits important details
    • 0 - little to no effort, or submitted an RTF/DOC/PDF file instead of plain TXT
  • 4 point - for valid test1.cl-tac and test2.cl-tac files
    • 4 - wide range of testing, stressing many features
    • 2 - added some tests, but the scope not sufficiently broad
    • 0 - little to no effort
  • 1 point - for a correct team.txt file
    • 1 - file contains a single word: the uva email address of your partner (e.g., wrw6y)
    • 1 - file is not present at all, and you are working alone
    • 0 - file is present but contains something other than the single word of your partner's email address

CA2: Three-Address Code

• Project Handout
• Grading (out of 50)
  • 41 points - for autograder tests
    • Each missed test (i.e., each instance of the word "FAILED" in the report) removes points, to a minimum of 0/41, even if there are more tests than total points.
  • 4 points - for a clear description in your README
    • 4 - thorough discussion of design decisions (including language comparisons) and choice of test cases; a few paragraphs of coherent English sentences should be fine
    • 2 - vague or hard to understand; omits important details
    • 0 - little to no effort, or submitted an RTF/DOC/PDF file instead of plain TXT
  • 4 point - for valid test1.cl and test2.cl files
    • 4 - wide range of testing, stressing many expression features and control-flow notions
    • 2 - added some tests, but the scope not sufficiently broad
    • 0 - little to no effort
  • 1 point - for a correct team.txt file
    • 1 - file contains a single word: the uva email address of your partner (e.g., wrw6y)
    • 1 - file is not present at all, and you are working alone
    • 0 - file is present but contains something other than the single word of your partner's email address

CA3: Code Generation

• Project Handout
• Grading (out of 50)
  • 41 points - for autograder tests
    • You lose 1 point per failed test, but the maximum number of points lost per test program is capped at 4 (even if programs have multiple inputs). The minimum score is 0/41.
  • 4 points - for a clear description in your README
    • 4 - thorough discussion of design decisions (including language comparisons) and choice of test cases; a few paragraphs of coherent English sentences should be fine
    • 2 - vague or hard to understand; omits important details
    • 0 - little to no effort, or submitted an RTF/DOC/PDF file instead of plain TXT
  • 4 point - for valid test1.cl and test2.cl files
    • 4 - wide range of testing, stressing many integer, boolean and control-flow features
    • 2 - added some tests, but the scope not sufficiently broad
    • 0 - little to no effort
  • 1 point - for a correct team.txt file
    • 1 - file contains a single word: the uva email address of your partner (e.g., wrw6y)
    • 1 - file is not present at all, and you are working alone
    • 0 - file is present but contains something other than the single word of your partner's email address

CA4: The Compiler

• Project Handout
• Grading (out of 100)
  • 70 points - for autograder tests
    • Each missed test removes points, to a minimum of 0/70, even if there are more or fewer tests than total points.
  • 5 points - for a correct CA4t submission
  • 1 point - for a correct team.txt file
    • 1 - file contains a single word: the uva email address of your partner (e.g., wrw6y)
    • 1 - file is not present at all, and you are working alone
    • 0 - file is present but contains something other than the single word of your partner's email address
  • 8 points - for a clear description in your README
    • 8 - thorough discussion of design decisions (e.g., the handling of let and new and dispatch) and choice of test cases; a few paragraphs of coherent English sentences should be fine
    • 4 - vague or hard to understand; omits important details
    • 0 - little to no effort, or submitted an RTF/DOC/PDF file instead of plain TXT
  • 8 point - for valid test1.cl, test2.cl, test3.cl and test4.cl files
    • 8 - wide range of test cases added, stressing most Cool features and some error conditions
    • 4 - added some tests, but the scope not sufficiently broad
    • 0 - little to no effort
  • 8 point - for code cleanliness
    • 8 - code is mostly clean and well-commented
    • 4 - code is sloppy and/or poorly commented in places
    • 0 - little to no effort to organize and document code

CA5: The Optimizer

• Project Handout
• Grading (out of 100)
  • 67 points - for optimizer performance tests
    • -0 - performance better than "reference --opt"
    • -17 - performance better than "reference" but worse than "reference --opt'
    • -33 - performance worse than "reference"
    • -67 - performance worse than "0.9 * reference"
  • 1 point - for a correct team.txt file
    • 1 - file contains a single word: the uva email address of your partner (e.g., wrw6y)
    • 1 - file is not present at all, and you are working alone
    • 0 - file is present but contains something other than the single word of your partner's email address
  • -50 points - hard-coding some benchmark files rather than writing a generic optimizer
  • -20 points - total failure to implement control-flow graphs, liveness and dead code elimination
  • -10 points - partial failure to implement control-flow graphs, liveness and dead code elimination
  • 16 points - for a clear description in your README
    • 16 - thorough discussion of design decisions (e.g., the handling of the control flow graph, live variable analysis, dead code elimination, how code generation and intermediate representations relate, other optimizations performed) and choice of benchmarks; multiple paragraphs of coherent English sentences are required
    • 8 - vague or hard to understand; omits important details
    • 0 - little to no effort, or submitted an RTF/DOC/PDF file instead of plain TXT
  • 8 point - for valid benchmark1.cl and benchmark2.cl
    • 8 - both examples take 50,000 instructions or fewer to execute via the reference compiler with --asm --profile
    • 4 - one benchmark is not valid
    • 0 - no valid benchmarks included
  • 8 point - for code cleanliness
    • 8 - code is mostly clean and well-commented
    • 4 - code is sloppy and/or poorly commented in places
    • 0 - little to no effort to organize and document code