PA5 — Compiler/Code Generator

Project Overview

PA5 is due 12/6 at 11:59pm Central. There are absolutely no extensions or late days for this assignment.

You must complete this assignment in Python.

You may work in a team of up to two people for this assignment. You may work in a team for any or all subsequent programming assignments. You do not need to keep the same team. The course staff are not responsible for finding you a willing team. If you want to work on a team, you must register your group on the autograder before submitting!

Goal

For this assignment, you will write a program that takes a Cool annotated abstract syntax tree and produces either Cool Assembly or x86-64 assembly. You will be given a Cool Annotated Abstract Syntax Tree (see PA4 specification for details). From this annotated AST, you must generate ASM code.

You do not have to worry about malformed input because the semantic analyzer (from PA4) has already ruled out bad programs. You will track enough information to generate legitimate run-time errors (e.g., dispatch on void). Among other things, this assignment involves implementing the operational semantics specification of Cool.

The Specification

You must create three artifacts:

1. A program, main.py that takes a single command-line argument (e.g., file.cl-type). That argument will be a Cool Annotated Abstract Syntax Tree file coresponding to one or more classes and methods. The cl-type file will always be well-formed (i.e., there will be no errors in the cl-type file). That is, every test case you receive can be compiled successfully. Your program must emit either Cool Assembly Language (file.cl-asm) or x86-64 Assembly Language (file.s). In addition to main.py, you can include up to 20 additional *.py files.
• If you are targeting Cool Assembly Language, then executing file.cl-asm must produce the correct output for file.cl according to Cool's operational semantics.
• If you are targeting x86-64, then compiling file.s with gcc on 64-bit Linux must produce an executable that, when run, produces the correct output for file.cl according to Cool's operational semantics.
• You will only be given .cl-type files from programs that pass the semantic analysis phase of the reference compiler. You are not responsible for correctly handling programs that are semantically invalid (e.g., that include something like 1+"hello").
2. A plain ASCII text file called readme.txt describing your design decisions and choice of test cases. See the grading rubric. A few paragraphs should suffice.
3. Test cases test1.cl, test2.cl, test3.cl, and test4.cl. These test cases should exercise compiler and run-time error corner cases.

Error Reporting

You are guaranteed that the file.cl-type input file will be correctly formed and will correspond to a well-typed Cool program. Thus, there will not be any direct static errors in the input. Those were all caught by the semantic analyzer earlier.

However, you must generate file.cl-asm (or file.s) so that it checks for and reports run-time errors. When your file.{cl-asm,s} program detects an error, it should use the Syscall IO.out_string and Syscall exit assembly instructions to cause an error string to be printed to the screen.

To report an error, write the string ERROR: line_number: Exception: message (for example, using Syscall IO.out_string) and terminate the program with Syscall exit. You may generate your file.{cl-asm,s} so that it writes whatever you want in the message, but it should be fairly indicative. Example erroneous input:

class Main inherits IO {
  my_void_io : IO ; -- no initializer =\> void value
  main() : Object {
    my_void_io.out_string("Hello, world.\n")
  } ;
} ;

For such an input, you must generate a well-formed file.{cl-asm,s} assmebly language file. However, when that file is executed (either in a Cool CPU Simulator or on an x86-64 machine), it will produce output such as:

ERROR: 4: Exception: dispatch on void

To put this another way, rather than actually checking for errors directly, you must generate assembly code that will later check for and report errors.

Line Number Error Reporting

The typing rules do not directly specify the line numbers on which errors are to be reported. As of v1.25, the Cool reference compiler uses these guidelines:

• Stack overflow: undefined (not your responsibility)
• Division by zero: location of the division expression
• Substring out of range: location of the internal expression (i.e., 0)
• Dispatch on void: location of dispatch expression
• case-related errors: location of case expression

Note that the reference interpreter uses different line numbers in some cases; you must match the reference compiler.

Video Guides

NOTE: Some of these video guides are from a previous offering of a similar course at the University of Virginia. The assignment for this semester has changed slightly (and, in this case, was named differently). While they are still relevant, you are responsible for completing the assignment according to this course's grading rubric.

A Video Guide is provided to help you get started on this assignment on your own. The Video Guides are a walkthrough in which the instructor manually completes and narrates, in real time, the first part of this assignment. It includes coding, testing and debugging elements.

If you are still stuck, you can post on the forum, approach the TAs, or approach the professor. The use of online instructional content outside of class weakly approximates a flipped classroom model. Click on a video guide to begin, at which point you can watch it fullscreen or via Youtube if desired.

What To Turn In For PA5

You must submit the following files to the autograder:

1. readme.txt — your README file
2. Your source files — including
   • main.py
   • up to 20 additional *.py files (e.g., if you want to split up your code across multiple modules).
3. 5 test cases
• test1.cl
• test2.cl
• test3.cl
• test4.cl
• test5.cl

Autograding

We will use scripts to run your program on various testcases. The testcases will come from the test1.cl-type and test2.cl-type files you and your classsmates submit as well as held-out testcases used only for grading. Attempting to subvert the autograder (e.g., submitting a copy of the reference compiler, or attempting to reveal the contents of held-out test cases) is a violation of the honor code and will result in a 0 for the assignment or course.

We will execute your submission using python3 main.py some_file.cl-type

Students frequently split their submissions into multiple files (e.g., one module for deserializing the input, another to implement AST node structures, etc.).

In each case we will then compare your output to the correct answer. If your compiler changes the meaning of the program, you will get 0 points for that testcase. Otherwise, you get 1 point for that test case.

Do not create any temporary files. The autograder will invoke your submission using python3 main.py some_file.cl-type.

Grading Rubric

• Grading (out of 110 points)
• 85 points for autograder tests
• +1 point for each passed good test case (77 total)
• +1 point for each passed bad test case (8 total)
• +0 point for each failed test case (i.e., that either fail to compile, or whose resulting program executes incorrectly)
• If you implement an x86-64 compiler, you will get +20 points (up to a maximum of 85/85).
• 10 points for valid test1.cl, test2.cl, test3.cl, test4.cl, and test5.cl files
• +2 points each — high quality tests
• +1 point each — valid tests that do not stress challenges in compilation
• +0 points — test cases showing no effort
• 8 points for readme.txt file
• +8 points — a clear, thorough description of compiler design and test cases
• +4 points — a vague or unclear description omitting details
• +0 points — little effort or if you submit an RTF/DOC/PDF instead of a plain TXT file
• 7 points for code cleanliness
• +7 points — clear, well-documented code that is well-organized
• +3 points — code is unclear or poorly documented in some places
• +0 points — code is messy, sloppy, or disorganized