This repository contains the specifications for the three lab exercises for the Compilers module.
The three exercises are:
1 - Lexers and regular expressions (due Tue 1 Feb at 23:59).
2 - Parsers and ASTs (due Tue 15 Feb at 23:59).
3 - Code Generation (due Tue 01 Mar at 23:59).
The primary purpose of the lab exercises is to ensure that everyone learns the basic skills needed for the coursework. They are not designed to be too challenging, but they do require you to get to grips with several tools and concepts that you will need later.
The three exercises are equally weighted, and are together worth 20% of your Compilers mark (and hence 10% of your IAC mark).
The exercises will be marked in a largely automated fashion. I will compile your code and run it against a collection of my own inputs. Please note that it is very important to test that your code compiles and runs correctly. Failure to do so could result a mark of zero for that exercise.
Feedback will be largely in terms of what works and what doesn't work. I hope to provide formal feedback within ten working days. You are also encouraged to seek informal feedback on your code from the teaching assistant, your tutor, and your peers.
The target environment for the labs (and the coursework) is Ubuntu 20.04. It is strongly suggested that you do your final testing before each submission in this environment, otherwise you are likely to hit incompatibility problems, which may mean your program won't build. Those using Mac OS should watch out in particular, as the build environment is often subtly different.
If you want to work on your own machine (which is encouraged), you can install a version of Ubuntu quite easily. For this, you may wish to use VirtualBox together with Vagrant. Another option for Windows users is to use the Windows Subsystem for Linux (WSL), preferably WSL 2 for the most compatibility.
This repository contains a Vagrantfile, which is a script that sets up a blank Ubuntu 20.04 environment, and then installs all the tools that the lab exercises require. To start a virtual machine (VM) using Vagrant, follow these steps.
Open a shell in this directory.
Run vagrant up to download, install, and configure the VM.
Run vagrant ssh to log into the VM.
Run cd /vagrant : This will put you in the same directory, with
your host files shared with the VM.
You can then use command line build tools in the VM, while editing the source files in your host editor.
If you want to stop the machine,
Run exit to exit the session,
Run vagrant halt to shut down the virtual machine.
If you later run vagrant up again, it will not need to download the VM from scratch.
WSL is a builtin linux environment in Windows, which makes it much easier to work with than a VM. It is then recommended to use WSL 2 to get the most compatibility with the Linux environment used by Vagrant above.
NOTE: When using WSL, there might be slight incompatibilities with the lab environment used for marking, so to be sure that everything works, it's always recommended to test the repository on a full version of Ubuntu 20.04 using Vagrant before submitting.
To set up the lab environment, the following packages will be needed:
sudo apt-get update
# Standard build tools
sudo apt-get -y install g++ gdb make dos2unix git
# Compiler build tools
sudo apt-get -y install bison flex
# MIPS cross-compiler stuff
sudo apt-get -y install g++-mips-linux-gnu gdb-multiarch
# QEMU run-time emulator
sudo apt-get -y install qemuIt should then be possible to follow along with the lab normally.
git repositoryNOTE: As of this year, you will need to use a personal access token for cloning using HTTPS, or use an SSH key. You can set up a token by following these instructions, or an SSH key following these instructions.
A private repository has been created for you, which you can clone using the following command:
git clone https://github.com/LangProc/langproc-2021-lab-${LOGIN}.gitYou'll need to type in your GitHub credentials to authenticate, unless you've set up SSH authentication.
You are free to include any files you wish in your repository, such as notes or partial versions. However, try not check in compiled programs or large binary files. Repositories should contains the sources and instructions for binaries, but git does not deal well with binary files. Most repositories should contain a .gitignore file, which gives patterns for files that should not be committed. There is one included here which covers a few things, but feel free to add other temporary and binary files that your system might produce.
If there are any changes to the specification (e.g. bugs or updates), you can incorporate them into your version by pulling again from the specification repo. First you need to make sure it is included as a "remote":
git remote add spec https://github.com/LangProc/langproc-2021-lab.gitIf you now list the remotes, you should see both "origin" (your private repo), and "spec" (the specification repo):
git remote -vYou can now integrate changes from the specification repo by pulling from it:
git pull spec masterIf you have changed a file that also changed in the specification, then you may need to commit locally first. Look carefully at any incoming changes due to the pull, and make sure you want to accept them.
Submission of code is via your git repository. Make sure you have committed and pushed to GitHub all the files that your project needs. You are strongly encouraged to clone it into a different directory and then test again, just in case you are relying on something that wasn't committed.
Once your code is committed, note the commit hash of your current revision:
git log -1This will produce something like:
ubuntu@ubuntu-xenial:/vagrant$ git log -1
commit 94d8419b20c78da86415bea7236d3719915977a3
Author: John Wickerson <j.wickerson@imperial.ac.uk>
Date: Mon Jan 07 14:26:40 2018 +0000
All tests passing.The commit hash of this revision is 94d8419b20c78da86415bea7236d3719915977a3
which is a cryptographic hash over all the files in your
repository, including the history of all the files. The hash produced
on your local machine will also match the hash calculated
by GitHub.
So take your hash (and just the hash), and submit it via Teams. Even if GitHub goes down, you can later on prove that the existence of your hash in Teams means you must have done the work associated with the hash. The hash in Teams will also be the exact revision of your repository that will get checked out of GitHub and tested. So you can carry on editing and modifying the repository, but only the commit with the hash submitted to Teams will be tested.
To summarise:
Test your code on your machine.
Commit your code to your local repo.
Note the commit hash (git log -1).
Push the code to GitHub.
Check that the commit hash in the GitHub website matches your local hash.
Strongly recommended: clone your code to a completely different directory, and test it again.
Submit the hash via Teams.
You can repeat this process as many times as you want, up until the deadline.
The exercises were devised by Dr David Thomas (course lecturer until 2017-18), and are nowadays maintained by Dr John Wickerson.