Solutions to the lab exercises are accessible to tutors and demonstrators on a private page.
There are four lab exercises for the course:
- Implement control structures in a flowchart language.
- Add array access to a typed language
- Implement procedure calls, nested procedures and higher-order functions.
- Extend a code generator for the ARM to better exploit addressing modes.
Some of the exercises have optional parts that you may like to complete. It's more important, however, that you do at least the non-optional parts of all the labs, including the last one.
The lab exercises are described in Chapters 3, 5, 7 and 9 of the coursebook. Listings of the chief modules you will need to change are provided in Appendix E of the book. The lab materials are divided into several subdirectories:
||Assembler and bytecode interpreter for the Keiko abstract machine.|
||Source code for Lab 1: control structures.|
||Source code for Lab 2: arrays.|
||Source code for Lab 3: procedures.|
||Source code for Lab 4: machine code.|
||Extra library modules used in all our compilers.|
||Formatted output à la Mike.|
||Tracking and printing lines from the source code.|
||Useful functions missing from the standard library.|
||A complete compiler that translates the language of Lab 4 into Keiko bytecode.|
The materials are delivered using an anonymous Mercurial server in a way described in the instructions for Lab 1. You can also browse the materials using the URL
and there's a cheat sheet listing the commands you'll need to use.
If you're already familiar with Git, then the same materials are accessible as a Git repository at
If you're tempted to follow this route, be aware that the lab manual provides help only with Mercurial, though there is a cheat sheet giving some hints.
Please don't post on GitHub. Please note that the lab materials are protected by copyright, and more importantly it does no favours to future students if the answers become publicly available. What's more, a public clone is not likely (once you've lost interest in the course) to share any bugfixes made to the materials. It's for these reasons than I don't host the lab materials on GitHub, because there one natural way of working begins with making a public clone of the repository. It's not necessary to publish clone repositories in order to do the lab exercises, and I ask you, please, not to do so. – Mike.
Opne a shell window and use it to clone the Mercurial repository containing the materials by using the command,
$ hg clone http://spivey.oriel.ox.ac.uk/hg/compilers
This will make a directory called
compilers containing all the materials.
Now change to the subdirectory
compilers/keiko and build the interpreter for the Keiko machine:
$ (cd compilers/keiko; make)
(The parentheses here make the change of directory local to the command.)
Second, change to the subidrectory
compilers/lib and build some utility modules that are common to all our compilers:
$ (cd compilers/lib; make)
Next, you can change to the subdirectory for one of the labs and build the initial version of it:
$ cd compilers/lab1 $ make
Finally, you can run regression tests on the resulting compiler:
$ make test
You'll find the first test
gcd.p already passes. But the second test uses features that the lab asks you to implement, so it will fail until you've done the lab exercise. When your work is done, all tests will pass.
You are free to use whatever software you prefer for editing and for building and testing programs, but it's best to use Make with the Makefiles provided, and to choose an editing platform that is able to interpret error messages in the standard format and take you to the relevant line of the source code. I've provided project files for Geany, a lightweight IDE, that you can use if you like. Another page gives instructions for setting up the project files and starting to use Geany.
Naturally enough, the computers in the Software Lab have been set up with all the software that is needed to do these exercises. If you want to use your own machine, that is perfectly possible, and another page gives suggestions for setting up the software you need. You will probably wish to do this well before the end of term so that you are set up for the Christmas assignment.
Problems and solutions
Problems marked "Fixed in rev n:1a2b34" can be resolved by pulling from the software repository then updating your working copy. Instructions for doing this are given on the Mercurial cheat sheet.
- 001 The
ocamlccompiler reports garbled source text in error messages for Lab 4.
- There's a bug in
ocamlcthat affects programs that are built using a text-based preprocessor like our
nodexpprogram: after a compile-time error, the fragment of the source file that is displayed becomes garbled. I've tried to work round this by providing a wrapper
tools/ocamlwrapthat invokes the
ocamlcin a way that disables the compiler's own display of source fragments, and instead inserts its own snippets. This wrapper is used in the Makefile each lab exercise.
Some little tools
- Lab four makes use of a preprocessor called
nodexpthat allows us to write operator trees with the concise syntax
<LOADW, <LOCAL 8>>
- instead of
Node (LOADW, [Node (LOCAL 8, )]).
- The preprocessor is implemented using a lexer and parser written with
- The diagrams of optrees in the lecture notes and on this site are generated with another software tool called
opdrawthat accepts an input syntax similar to nodexp and compiles it into the Metapost graphics language.
- Also in Lab four, there is a script that allows programs in ARM assembly language to be sent to a remote Raspberry Pi, where they are assembled, linked and executed.
Here, for safety's sake, is a tarball containing the same materials: compilers.tar.gz. After downloading it, you can unpack it and create a local Mercurial repository with the commands
$ tar xvfz compilers.tar.gz $ cd compilers $ hg init $ hg add . $ hg ci -m 'Initial revision'