A Compiler for Klein

Source Language

the Klein logo

Klein is a small, mostly functional programming language that is designed specifically to be used as a manageable source language in a course on compiler design and implementation. Though small and simple, the language is Turing-complete.

Here is the language specification for Klein. Know it well! +

Here is a directory of Klein programs that you can use to exercise the stages of your compiler. You can also download a zip file containing the same directory and programs.
(last update: 2025/12/08 — add tests-pr06/)

Three notes:

By convention, .kln is the standard extension or Klein source files. Please follow this standard, as it allows other tools to assume the extension as a default.
This set of files is not sufficient to test all of the features of your compiler as you write it. It does not contain all error cases, nor does it provide a systematic coverage of Klein features.
Without a Klein compiler to use as a reference, it is possible that one or more of these programs contains an error. As you study the Klein grammar early in the project, use these programs to verify your understanding. If you find a Klein program that seems to violate the language specification, let me know immediately. This will help us debug the grammar, the program, or your understanding.

I will add files to this set over time. Please send me any interesting Klein programs that you write!

Target Language

Your compiler will generate as output programs written in the assembly language of TM, the "tiny machine" created by Kenneth Louden. Here is the machine specification for TM and its assembly language.

By convention, .tm is the standard extension for TM source files.

You can download a software implementation of TM either as a zip file or as individual files from this directory.
(last update: 2025/10/23 — fixed link to zip file)

The directory contains five C programs, which are a sequence of TM simulators:

a version essentially identical to the machine defined in Louden's textbook, with a small change to eliminate a run-time warning
a version that takes command-line arguments
a version that executes the TM program immediately, rather than interacting with the user through a menu. This version of the simulator can be useful when we trust that our compiler is correct and are most interested in its performance. It can also be useful for debugging Klein programs.
a version that reports the number of clock ticks consumed by program execution. This version of the simulator can be useful in comparing implementations and optimizations.
a version that extends the size of memory available for both program instructions and program execution. This version of the simulator can be useful for compiling large Klein programs and for running Klein programs with deep call stacks.

It also contains two versions of a sample TM program from Louden's text.

Project Modules

You will build your compiler in phases. Links are added as modules are assigned. (The dates are tentative. We may modify them as we proceed through the semester.)

scanner — due Friday, September 19
parser, step 1 — due Friday, October 3
parser, step 2 — due Friday, October 17
semantic checker — due Friday, October 31
code generator, step 1 — due Friday, November 14
code generator, step 2 — due Friday, December 5
final submission — due Friday, December 12

Your six deliverables for the project will consist of a single project directory that you grow over the course of the semester.

Your compiler may contain only code written by you, by one of your teammates, or by a program that you write. It should contain no code written by any other person or generated by any program that you did not write.

Project Teams

Forming Teams

You will build your compiler as part of a team. Teams ordinarily consist of three or four students.

I will divide the class into teams based on preferences that students express on a survey that is part of Homework 00, completed during the first week of the semester.

If you don't feel confident in your abilities, consider working with someone who does. If you are more confident, please consider working with someone who could use extra support.

Each team is required to select a team leader, or captain, who will serve as the primary contact for the team.

Managing the Project

Working together and managing a project are two of the skills that a project course asks you to practice and develop. They are an important skills for you to bring to your professional lives. They also usually require work and compromise.

Your Project Management course introduces you to a set of tools that will be useful for managing your project. These tools are primarily solutions to technical problems. The social side of managing a project is just as important, and often the bigger challenge.

Here are some management tips that you can use to organize and run your project. I suggest that you read through these tips and use them with your team.

Working Together

Working as part of a team to implement a significant software system can be a rewarding experience. It also comes with responsibility, because now your work affects not only yourself but also your teammates.

The following guidelines are in place in an effort to maximize the chances that you and your teammates have a positive experience working together — and to maximize the chances that your team delivers a working compiler at the end of the course.

You must commit to meeting regularly as a team. I suggest scheduling a regular meeting time and place, if at all possible.
You may do some of your work asynchronously, but you have to spend at least half of your time working together at the same time. This work can include designing modules, writing or reviewing code, debugging the module, testing and correcting the module, or writing programs in the source language.
I recommend that you consider pair programming if possible, or programming as a team. Even strong programmers can have more fun working together than working alone. Working together also helps you learn from one another as you work and to have a better collective understanding of the code your team produces.
Regardless of how you choose to work, I expect that each team member understands the entire codebase that the team submits, even the code developed by other team members. Each team member should be prepared to answer questions about specific implementation decisions and specific details of the code.

As you proceed through the project, I encourage you and your teammates to reflect on what is going well for the team and what can be improved, both technically and collaboratively. You can adjust the team's practices in response to its results.

Feel free to contact me if I might be of assistance to your team as you navigate the project.

Evaluating Contributions

At the end of the course, each team member must submit an evaluation of the team's work and of each team member's contribution to the success of the project. I will take these evaluations into account when I assign grades for each team member's contribution to the success of the project.