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.

Language Guides

• C will only be used in Programming Assignment 1 and in some additional assignments related to linking and multi-language projects. However, C generally serves as the lingua franca of the programming languages world, and you will find that many other tools (e.g., lexical analyzer generators) explain themselves with respect to similar C implementations.
• When in doubt, support gcc version 4.1.2 20080704 (Red Hat 4.1.2-51), x86_64-redhat-linux.
• (The x86_64 assembly output for PA6 and PA7 is also known to work on gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) x86_64-redhat-linux).

• See the course webpage and reference maunal on Cool.

• The Haskell documentation for version 7.0.4.
• The latest standard libary API documentation.
• Download Haskell.
• When in doubt, support The Glorious Glasgow Haskell Compilation System, version 7.0.4 (with available library mtl 2.0.1.0 for Control.Monad.State and missingH 1.2.1.0 for general utility).

• The API reference manual.
• Download the Node.js JavaScript interpreter.
• When in doubt, support Node.js v0.10.24.

• The Reference Manual
• Download OCaml
• When in doubt, support The Objective Caml compiler, version 3.12.1.
• If you use Eclipse, try the OCaIDE plug-in for Eclipse.

• Python Main Page
• Download Python
• Python For Java Programmers
• When in doubt, support Python 2.6.5. (If you use features, functions or syntax added in newer verisons of Python, your code may not work on our grading servers.)

• Ruby Main Page
• Ruby Documentation
• Download Ruby
• When in doubt, support ruby 1.8.5 (2006-08-25) [x86_64-linux]. It may be available here. You can also try the Ruby Verison Manager project.

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).

PA1: The Rosetta Stone

• Project Handout (also covers PA1c)
• Project Files
  • pa1-hint.zip - Shows the same simple program written in six languages.
  • pa1-testcases.zip - Gives five "starter" testcases to help you evaluate your work.
• Grading (out of 50)
  • 40 points - for autograder tests (max 40/6 points per language)
    • Each missed test removes points, to a minimum of 0/40, even if there are more tests than total points.
  • 5 points - for a correct PA1c submission
  • 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
  • 1 point - for a valid testcase.list file

PA2: The Lexer

• Project Handout
• Grading (out of 50)
  • 37 points - for autograder tests (-1 point per failed test, minimum score of 0)
    • Each missed test removes points, to a minimum of 0/37, even if there are more tests than total points.
  • 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
  • 4 points - for a clear description in your README
    • 4 - thorough discussion of design decisions (including handling of strings and comments) 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
  • 4 point - for valid good.cl and bad.cl files
    • 4 - wide range of test cases added, stressing most Cool features and an error condition
    • 2 - added some tests, but the scope not sufficiently broad
    • 0 - little to no effort, or submitted an RTF/DOC/PDF file instead of plain TXT
  • 4 point - for code cleanliness
    • 4 - code is mostly clean and well-commented
    • 2 - code is sloppy and/or poorly commented in places
    • 0 - little to no effort to organize and document code

PA3: The Parser

• Project Handout
• Grading (out of 50)
  • 37 points - for autograder tests (-1 point per correct test, minimum score of 0)
    • Each missed test removes points, to a minimum of 0/37, even if there are more tests than total points.
  • 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
  • 4 points - for a clear description in your README
    • 4 - thorough discussion of design decisions (e.g., the handling of let) 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 good.cl and bad.cl files
    • 4 - wide range of test cases added, stressing most Cool features and an error condition
    • 2 - added some tests, but the scope not sufficiently broad
    • 0 - little to no effort
  • 4 point - for code cleanliness
    • 4 - code is mostly clean and well-commented
    • 2 - code is sloppy and/or poorly commented in places
    • 0 - little to no effort to organize and document code
  • -5 points - if you neglected to include the grammar definition
    • 0 - included grammar definition in submission (e.g., .mly file, PLY file defining grammar, .y file for racc, etc.)
    • -5 - only submitted machine-generated parser; failed to submit grammar from which parser was generated

PA4: The Semantic Analyzer

• Project Handout
• Grading (out of 100)
  • 65 points - for autograder tests
    • Each missed test removes points, to a minimum of 0/65, even if there are more tests than total points.
  • 5 points - for a correct PA4t submission
  • 5 points - for a correct PA4c 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., handling of the class hierarchy, case 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 good.cl, bad1.cl, bad2.cl and bad3.cl files
    • 8 - wide range of test cases added, stressing most Cool features and three 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
• (The "PA4 Semantics Checkpoint" and "PA4 Preliminary Testing Exercise" together count as a single Written Assignment and are graded separately.)

PA5: The Interpreter

• Project Handout
• Grading (out of 100)
  • 65 points - for autograder tests
    • Each missed test removes points, to a minimum of 0/65, even if there are more tests than total points.
  • 5 points - for a correct PA5t submission
  • 5 points - for a correct PA5c 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

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

PA6: 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 valid PA6c 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

PA7: 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
  • -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