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
Introduction
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:
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 yourdoc/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 ofprograms/. -
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
READMEfile 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 theREADMEin yourmisc/directory or yourdoc/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.
- Make deliberate decisions about which features to leave in your compiler and which features to leave out.
-
Document any omissions and other design decisions
prominently in the "basic description of project" section of
your
READMEfile. - Have your compiler print suitable error messages whenever it encounters a language feature that is not supported.
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.