Operating System Design :: Projects :: Compiler Part 2
Problem
The files for this project are in the projects directory under 11 when you downloaded the class software.
You will need two tools: the programming language with which you will implement your compiler and the supplied VM Emulator utility (available in your tools directory) for testing the code generated by your compiler.
Instructions
Chapter 11 includes a proposed, language-independent Compiler API, which can serve as your implementation's blueprint. The proposed implementation is based on morphing the syntax analyzer built in the previous project into a the final compiler. In particular, we propose to gradually replace the software modules that generate passive XML output with software modules that generate VM code. This can be done in two main development stages, as follows.
Stage I: Symbol Table: We suggest to start by building the compiler's symbol table module and using it to extend the syntax analyzer built in Project 10. Presently, whenever an identifier is encountered in the source code, say foo, the syntax analyzer outputs the XML line "<identifier> foo </identifier>". Instead, have your analyzer output the following information as part of its XML output (using some output format of your choice):
- The identifier's name, as done by the current version of the syntax analyzer.
- The identifier's category: var, argument, static, field, class, or subroutine.
- If the identifier's category is var, argument, static, or field, the running index assigned to the identifier by the symbol table.
- Whether the identifier is presently being defined (e.g. the identifier stands for a variable declared in a "var" statement) or used.
You may test your symbol table module and the above capability by running your extended syntax analyzer on the test Jack programs supplied in Project 10. Once the output of your extended syntax analyzer will include the above information, it means that you have developed a complete executable capability to understand the semantics of Jack programs. At this stage you can make the switch to a full-scale compiler, and start generating VM code instead of XML output. This can be done by gradually morphing the code of the extended syntax analyzer into a full-scale compiler.
Stage II: We don't provide specific guidelines on how to develop the code generation features of the compiler (except for the examples given in Chapter 11). Instead, we provide a set of six application programs designed to unit-test these features incrementally. We strongly suggest to test your compiler on these programs in the given order. This way, you will be implicitly guided to build the compiler's code generation capabilities in stages, according to the unfolding demands of each test program.
Testing
Normally, when you compile a program and run into some problems, you conclude that the program has errors and proceed to debug it. In this project the setting is exactly the opposite: all the Jack programs that we supply for testing purposes are error-free. Therefore, if their compilation yields any errors, it's the compiler that you have to fix, not the test programs.
For each test program, go through the following routine:
- Compile the program directory using your compiler. This action should compile all the .jack files in the directory into corresponding .vm files;
- Inspect the generated .vm files. If there are any visible problems, fix your compiler and go to step 1 (remember: all the supplied test programs are error-free);
- Test the translated VM program by loading the program directory into the supplied VM Emulator and executing it using the "no animation" mode. Each one of the six test programs contains specific execution guidelines, as listed below; test the program according to these guidelines;
- If the test program behaves unexpectedly or some error message is displayed by the VM Emulator, fix your compiler and go to to step 1.
