Laboratory exercises

From Compilers
Jump to navigation Jump to search

Solutions to the lab exercises are accessible to tutors and demonstrators on a private page.

There are four lab exercises for the course:

  1. Implement control structures in a flowchart language.
  2. Add array access to a typed language
  3. Implement procedure calls, nested procedures and higher-order functions.
  4. 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. In addition, there is an entirely optional Lab 0 that provides an introduction to compiling and running OCaml programs.

The exercises

The lab exercises are described in Chapters 3, 5, 7 and 9 of the coursebook, with a separate set of instructions for Lab 0. 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:

keiko Assembler and bytecode interpreter for the Keiko abstract machine.
lab0 Source code for an initial, introductory exercise.
lab1 Source code for Lab 1: control structures.
lab2 Source code for Lab 2: arrays.
lab3 Source code for Lab 3: procedures.
lab4 Source code for Lab 4: machine code.
lib Extra library modules used in all our compilers.
 – bytes Compatibility code to emulate the Bytes module in earlier versions of OCaml.
 – growvect Extensible arrays.
 – print Formatted output à la Mike.
 – source Tracking and printing lines from the source code.
ppc A complete compiler that translates the language of Lab 4 into Keiko bytecode
tools The nodexp tool used to implement optree syntax, plus scripts for running ARM code on a remote server

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.

Some little tools

  • Lab four makes use of a preprocessor called nodexp that 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 ocamllex and ocamlyacc.
  • The diagrams of optrees in the lecture notes and on this site are generated with another software tool called opdraw that 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. [Until Mike gives this course again, the Raspberry Pi providing this service is likely to remain switched off: it's just too high maintenance to be left going without constant monitoring.]

Quick start

Clone the Mercurial repository containing the materials by using the command,

$ hg clone

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.

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 ocamlc compiler reports garbled source text in error messages for Lab 4.
There's a bug in ocamlc that affects programs that are built using a text-based preprocessor like our nodexp program: 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/ocamlwrap that invokes the ocamlc in 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 for Lab 4.

Using your own machine

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.

Safety net

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 Mercurial repository with the commands

$ tar xvfz compilers.tar.gz
$ cd compilers
$ hg init
$ hg add .
$ hg ci -m 'Initial revision'