There are two components to the coursework:
-
Worth 90%:
-
Worth 10%:
- Overall design style and code readability. This has been introduced to reward thoughtful planning throughout the project, rather than penalise you. There are no strict guidelines, but you should consider the use of abstraction, your internal representation of instructions, proper Git use, signs of appropriate testing, as well as general code hygiene.
- Evidence of time-tracking/project management. This will be assessed orally at the start of Summer term. See here for more information about this component.
Each group gets a bare private repository. It is up to you if you want to clone the main specification, or to start from scratch.
The deadline for submitting your C compiler is Friday 22 March 2024 at 23:59. There is no deadline for the project management component; instead, this will be assessed by a short oral viva that will be organised in Summer term.
Submission will be via GitHub (code) and Teams (commit hash), as in the labs.
All submissions will be tested functionally -- there is no expectation for your compiler to optimise its input. Moreover, your compiler will only be tested on valid inputs, so you do not need to handle faulty inputs in a graceful way.
-
New for 2023/2024:
- Provided guidance to generate coverage information.
- Expanded features list and provided a visual test case distribution.
- Included useful links to Godbolt, simulator, ISA, ABI, Assembler reference.
- Directly linked to ANSI C parser and lexer.
- Added a "Getting started" guide and incorporated last year's feedback from Ed.
- Changed the 10% of the grade (previously only for time management) to also account for code design to reward thoughtful planning.
- Improved the skeleton compiler to be more advanced by integrating lexer and parser to hopefully jump-start progress and avoid unnecessary debugging.
- Covered assembler directives in more details by showcasing the meaning behind an example assembly program, because that topic had always caused confusion in the past years.
- Added an improved testing script written in Python.
-
New for 2022/2023:
- Target architecture is now RISC-V rather than MIPS, in order to align with the modernised Instruction Architectures half of the module.
- Instead of Vagrant, Docker is now used for the testing environment (with optional VS Code support).
- Test scripts are now provided to check your compiler against the set of public tests, without having to write this yourself.
- The basic compiler framework has been improved to support command line arguments.
- GitHub Actions can now perform automated testing of your compiler.
-
New for 2021/2022:
- Various improvements to scripts for running test cases.
-
New for 2020/2021:
-
In previous years, students were additionally required to submit a C-to-Python translator, as a "ramping up" task. This extra deliverable has been removed, as the labs provide plenty of "ramping up" practice.
-
We have provided a really basic compiler that simply ignores its input and produces a fixed, valid RISC-V assembly program. This should help you to get started a bit more rapidly.
-
-
New for 2019/2020:
-
In previous years, students were additionally required to submit a set of testcases. This deliverable has been removed; instead, a large collection of testcases has been provided for you, as this was judged to be more useful.
-
In previous years, the compiler component counted for 42.8% of the module; it now counts for 55%. It was felt that this weighting more accurately reflects the effort that students put in to building a working compiler.
-
- The coursework was originally designed by David Thomas, who lectured this module until 2017-18. It is nowadays maintained by John Wickerson, to whom any feedback should be sent.
- Thanks to Yann Herklotz for making various improvements to the compiler-testing scripts.
- Thanks to Archie Crichton for providing a basic "getting started" compiler.
- Thanks to James Nock for overhauling the scripts for configuring the development environment, for writing detailed instructions for setting this up on various operating systems, and for creating GitHub actions capable of automatically testing compilers.
- Thanks to Quentin Corradi for setting up coverage testing and writing a getting-started guide for that.
- Thanks to Filip Wojcicki for overhauling the coursework specification and providing a new getting-started guide.