Module 7:
A Compiler for Klein

Stage 7 of the Klein compiler project
Out: Friday, December 5
Due: Friday, December 12, at 11:59 PM

Tasks

This stage consists of a complete implementation of your Klein compiler and a complete set of documentation.

1. A Complete Compiler

Your primary task is:

Ensure that all the components of your compiler satisfy the language specification and the project assignment.

This includes:

  • fixing any bugs that remain in any component of the compiler: scanner, parser, semantic analyzer, and code generator
  • making sure that your compiler traps all errors and handles them cleanly

Your compiler should never crash, even in the implementing language. As GCC's Have You Found a Bug? guide says, If the compiler gets a fatal signal, for any input whatever, that is a compiler bug. Reliable compilers never crash.

The code produced by your code generator should run in the TM simulator as configured in the download. If you would like to run experiments with other configurations, say, a larger data memory or instruction memory, be sure to document your experiments and corresponding changes to the configuration of TM prominently in your README file.

Your final submission should look and behave, to the best of your ability, like a professional software project.

If you are unable to implement a complete compiler for the entire Klein language, please follow the guidelines for an incomplete submission.

2. The Project Directory

Your secondary task is:

Ensure that your project directory conforms to all requirements.

This includes but is not limited to the following:

  • Clean up the directory.
    Remove any back-up files, files produced as side effects of compiling or running your compiler, extraneous files added by your IDE, and any other stray files.
  • Include all command-line tools.
    Make sure the five scripts that make up the command-line suite of your compiler are in the top-level directory and that they are executable at a Unix command line.
  • Clean up the source code for the compiler.
    This includes the documentation in each file.
  • Make sure that your documentation is complete.
    In particular, the files in your doc/ folder should have meaningful, consistent, and descriptive names.
  • Clean up the programs/ directory.
    It should contain all of the meaningful Klein source programs that your team wrote for the project and that each has a meaningful, descriptive name. If you include the programs from the standard Klein collection, place them in a subdirectory of programs/.
  • Clean up the tests/ directory.
    It should contain all of the Klein source programs and any other code you wrote for the sole purpose of testing your compiler and that each file has a meaningful, descriptive name. (Organizing the files in sub-directories may make your tests easier to understand.)
  • Create a README file for the final submission.
    This file documents the final complete compiler, not the earlier stages of the project. Make sure that it contains the required sections, that they are clearly labeled, and that it explains your final submission as clearly as possible. Place any earlier versions of the README in your misc/ directory or your doc/ directory, with names that indicate the date or stage of the compiler they relate to.

Your final submission should look and behave, to the best of your ability, like a professional software project.

3. An Improvement

Finally, if you have time and would like to earn extra credit, an optional task is:

Implement one new feature that improves the performance of your compiler.

The new feature must be in addition to what is implemented for Modules 1 through 6. Possible improvements include:

  • inlining some class of functions [ example ]
  • compiling recursive tail calls as gotos [ example ]
  • handling other tail calls without extending the stack [ example ]
  • implementing a more intelligent register selection utility [ example ]
  • generating excellent error messages designed for the error states in your parser, especially state-specific error messages [ example ]

The last of these improves the programmer's experience using your compiler. The first four affect the run-time behavior of the compiler by reducing size of the generated TM code, increasing the speed of the generated TM code, or extending the functional behavior of generated TM code.

Be sure to document this addition to your compiler prominently in the "basic description of project" section of your README file.

If you attempt an improvement or an optimization but are unable to complete it, be sure not to break your compiler. A complete, working compiler missing this final improvement is much more valuable than an almost improved compiler that does not work correctly.

Deliverables

As before, submit only one copy of each assignment per team. The team captain or a designated team member can be responsible for the submission.

Final Deliverable

By the due time and date, use the course submission system to submit your project directory electronically as a zip file named klein-compiler.zip or klein-compiler.tar.gz.

An Incomplete Submission

The goal of this project is to write a compiler for the entire Klein programming language. If you are unable to implement a complete compiler for the entire language, then your submission should reflect this is a professional manner, too.

Your compiler should work gracefully, even if for only a subset of the language. Your final submission should look and behave, to the best of your ability, like a professional software project. Delivering an incomplete implementation happens; even so, professionals deliver a professional product.