Commit 09f2f067 authored by Alexander Hirsch's avatar Alexander Hirsch
Browse files

Update for 2020

parent 7eee3ca7
# Compiler Construction # Compiler Construction (Draft)
| Date | Deadline | | Date | Topic / Recommended Schedule / Deadlines |
| ---------- | ------------------------------------------ | | ---------- | ----------------------------------------- |
| 2019-03-15 | [Example Input](example_input.md) | | 2020-03-03 | Introduction |
| 2019-04-05 | [Milestone 1](specification.md#milestones) | | 2020-03-10 | Lexer complete |
| 2019-05-03 | [Milestone 2](specification.md#milestones) | | 2020-03-17 | |
| 2019-05-24 | [Milestone 3](specification.md#milestones) | | 2020-03-24 | |
| 2019-06-14 | [Milestone 4](specification.md#milestones) | | 2020-03-31 | Parser complete |
| 2019-06-21 | [Milestone 5](specification.md#milestones) | | 2020-04-07 | *no proseminar* |
| 2019-07-12 | [Final](evaluation_scheme.md) | | 2020-04-14 | *no proseminar* |
| 2020-04-21 | Semantic checks complete |
| 2020-04-28 | |
| 2020-05-05 | AST → TAC conversion complete |
| 2020-05-12 | |
| 2020-05-19 | TAC → ASM (no function calls) complete |
| 2020-05-26 | |
| 2020-06-02 | TAC → ASM (with function calls) complete |
| 2020-06-09 | CFG generation complete |
| 2020-06-16 | Polish |
| 2020-06-23 | Build test submission deadline |
| 2020-07-14 | Final submission deadline (no extensions) |
- [mC Compiler Specification](specification.md) - [mC Compiler Specification](specification.md)
- [Getting Started Code-base](https://git.uibk.ac.at/c7031162/mcc) - [Getting Started Code-base](https://git.uibk.ac.at/c7031162/mcc)
...@@ -19,39 +30,46 @@ ...@@ -19,39 +30,46 @@
The ultimate goal of this course is to build a working compiler according to the given specification. The ultimate goal of this course is to build a working compiler according to the given specification.
You are not allowed to use code from other people participating in this course or code that has been submitted previously by somebody else. You are not allowed to use code from other people participating in this course or code that has been submitted previously by somebody else.
However, a *getting started* code-base is provided. A *getting started* code-base is provided, but you can also start from scratch.
You will be able to work on your compiler during the lab. During the lab, short QA sessions will be held.
You can work on your compiler in the meantime.
I'll be present for questions all the time, yet a big part of this course is to acquire the necessary knowledge yourself. I'll be present for questions all the time, yet a big part of this course is to acquire the necessary knowledge yourself.
Please note that minor modifications may be made to the specification until 1 week before the final deadline. Please note that minor modifications may be made to the specification until 2 weeks before the final deadline.
Therefore, double check for modifications before submitting — Git provides you the diff anyway. Therefore, double check for modifications before submitting — Git provides you the diff anyway.
Apart from this, there will be one *required* submission near the beginning of the semester.
You have to submit an additional example input, which may be added to the set of example inputs — this way the number of integration tests is extended.
Furthermore, there are five *optional* milestones.
They provide a golden thread and enable you to receive feedback.
You may work together in teams of 1–3 people. You may work together in teams of 1–3 people.
Teams may span across pro-seminar groups. Teams may span across pro-seminar groups.
## Grading ### Programming Language
The final grade is computed as the weighted average of the final submission (80%) and the QA sessions (20%). Any of the following programming languages can be used:
Both of these parts as well as the majority of QA session grades must be positive to pass this course.
Other submissions are not graded. - modern C (used for the getting started code-base)
- modern C++
- Go
- Rust
- Haskell
Be sure to adhere to the specification, deviating from it (without stating a proper reason) will negatively impact your grade. Go easy on external dependencies and obscure language extensions — yes, I'm looking at you, Haskell.
See [Final Submission Evaluation Scheme](evaluation_scheme.md) for more details. Code readability is paramount.
Using overly complex and cryptic concepts may negatively impact the evaluation process — again, looking at you, Haskell and your voodoo magic lenses.
### Evaluation System ### Evaluation System
I'll be using a virtualised, updated Ubuntu 18.04 LTS (64 bit) to examine your submissions. I'll be using a virtualised, updated Ubuntu 20.04 LTS (64 bit) to examine your submissions.
From this you can infer the software versions I'll be using. From this you can infer the software versions I'll be using.
The submitted code has to compile and run on this system. The submitted code has to compile and run on this system.
## Grading
The final grade is computed as the weighted average of the final submission (80%) and the QA sessions (20%).
Both of these parts as well as the majority of QA session grades must be positive to pass this course.
Be sure to adhere to the specification, deviating from it (without giving proper reason) will negatively impact your grade.
See [Final Submission Evaluation Scheme](evaluation_scheme.md) for more details.
### Absence ### Absence
You must not be absent more than three times to pass this course. You must not be absent more than three times to pass this course.
......
# Final Submission Evaluation Scheme # Final Submission Evaluation Scheme
Each checkbox represents 1 point to score.
The following key is used for calculating the resulting grade: The following key is used for calculating the resulting grade:
- **1:** ≥ 92% - **1:** ≥ 90%
- **2:** (92%, 84%] - **2:** [80%, 90%)
- **3:** (84%, 76%] - **3:** [70%, 80%)
- **4:** (76%, 68%] - **4:** [60%, 70%)
- **5:** < 68% - **5:** < 60%
It is required that for the *mandelbrot* test input, a respective executable can be built and run successfully. Points will be subtracted for shortcomings discovered during evaluation.
Points *may* be subtracted for shortcomings not explicitly listed in this form.
This includes things like: This includes things like:
- Encountered issues not mentioned or justified in the *Known Issues* section - Encountered issues not mentioned or justified in the *Known Issues* section
...@@ -24,92 +21,36 @@ This includes things like: ...@@ -24,92 +21,36 @@ This includes things like:
- Inconsistently formatted or unreadable source code - Inconsistently formatted or unreadable source code
- -
## Boundary Conditions ## Hard Requirements
- [ ] Correct submission
- Subject is correct
- Attached file has correct name and structure
- [ ] README is present
- Contains instructions
- Contains dependencies
- Contains *Known Issues*
- [ ] Code builds successfully
- Warnings are enabled
- No unjustified warnings of any kind
- [ ] All unit tests succeed
- [ ] All integration tests succeed
- provided test inputs must be included
- [ ] Additional integration tests (provided by the instructor) succeed
- [ ] Architecture consists of shared library + executables
- [ ] All symbols exported by the library are prefixed with `mcc_`
## Front-end
Errors need to come with a meaningful error message and source location information (filename, start line, and start column).
- Syntactic checks:
- [ ] Syntactically invalid mC programs are rejected with an error
- [ ] AST data structure is present and instantiated by the parser
- [ ] AST can be visualised using `mc_ast_to_dot`
- Semantic checks:
- [ ] Shadowing is supported correctly
- [ ] Error on use of undeclared variable
- [ ] Error on conflicting variable declaration
- [ ] Error on use of unknown function
- [ ] Error on missing `main` function
- [ ] Error on conflicting function names
- includes built-in functions
- [ ] Error on missing return-statement for non-void functions
- [ ] Correct type checking on scalars
- [ ] Correct type checking on arrays
- [ ] Error on invalid call-expressions
- Mismatching argument count
- Mismatching argument types
- Return type is taken into account by the type checker
- [ ] Symbol table data structure is present
- [ ] Symbol table can be visualised using `mc_symbol_table`
- [ ] Type checking can be traced using `mc_type_check_trace`
## Core
- [ ] TAC data structure is present - README is present:
- Contains list of prerequisites
- Contains build instructions
- Contains *Known Issues* section
- Submitted code builds successfully.
- `mcc` executable operates as demanded by the specification.
- A respective executable can be built and run for the *mandelbrot* test input.
- [ ] TAC can be visualised using `mc_ir` ## General (10 Points)
- [ ] CFG data structure is present This is all about compiling *valid* input programs.
- [ ] CFG can be visualised using `mc_cfg_to_dot` - Provided test inputs (examples) build and run successfully.
- Additional, secret test inputs build and run successfully.
## Back-end ## Front-end (8 Points)
- [ ] Assembly code can be obtained using `mc_asm` This is all about rejecting *invalid* input programs.
- [ ] GCC is invoked to generate the final executable - Invalid input yields a meaningful error message including source location (filename, start line, and start column).
- Syntactically invalid input is rejected by the parser.
- Semantic checks demanded by the specification are implemented and run on the obtained AST.
## Driver ## Core (2 Points)
- [ ] `mcc` executable supports the requested command-line flags The IR needs to be decoupled in order to exploit its benefits.
Furthermore, the control flow graph is an essential tool used by optimising compilers.
- [ ] Multiple input files are supported - TAC data structure is present and independent from front- and back-end.
- A dedicated CFG data structure is present.
- A CFG of a given IR function can be obtained and visualised.
# Example Input
Some example inputs for the compiler are already provided.
These examples are to be used as integration tests.
Your initial task is to create another example which may be added to the set.
Try to use as many features of the mC language as possible.
The example may read from `stdin` and write to `stdout` using the built-in functions.
Provide `.stdin.txt` and `.stdout.txt` files for verification purposes.
The getting started code-base provides a stub for the mC compiler.
It converts mC to C and compiles the result using GCC.
See [Submission Guideline](submission.md).
This diff is collapsed.
# Submission Guideline # Submission Guideline
- `XX` is to be replaced with the number of your team with leading zero (e.g. `02`). - Replace `XX` with your team number with leading zero (e.g. `02`).
- `Y` is to be replaced with the corresponding milestone number.
- One submission *per team*. - One submission *per team*.
## Example Input Submission ## Build Test Submission
Assuming your example input is named `mandelbrot`, zip the corresponding files like so:
mandelbrot.zip
└── mandelbrot/
├── mandelbrot.mc
├── mandelbrot.stdin.txt
└── mandelbrot.stdout.txt
Submit the zip archive via mail using the following line as subject (or link below).
List your team members in the mail body.
703602 - Example Input
📧 [send email](mailto:alexander.hirsch@uibk.ac.at?subject=703602%20-%20Example%20Input)
## Milestone Submission
1. `cd` into your repository. 1. `cd` into your repository.
2. Commit all pending changes. 2. Commit all pending changes.
3. Checkout the revision you want to submit. 3. Checkout the revision you want to submit.
4. Ensure everything builds. 4. Ensure the submitted code builds.
- Warnings are okay
- Tests may fail
- Memory may be leaked
- Known issues should be present
5. Run the following command: 5. Run the following command:
$ git archive --prefix=team_XX_milestone_Y/ --format=zip HEAD > team_XX_milestone_Y.zip $ git archive --prefix=team_XX_build_test/ --format=zip HEAD > team_XX_build_test.zip
6. Verify that the resulting archive contains everything you want to submit and nothing more. 6. Verify that the resulting archive contains everything you want to submit and nothing more.
7. Submit the zip archive via mail using the following line as subject (or link below). 7. Submit the archive via mail using the following line as subject (or link below).
703602 - Team XX Milestone Y 703602 - Team XX Build Test Submission
📧 [send email](mailto:alexander.hirsch@uibk.ac.at?subject=703602%20-%20Team%20XX%20Milestone%20Y) 📧 [send email](mailto:alexander.hirsch@uibk.ac.at?subject=703602%20-%20Team%20XX%20Build%20Test%20Submission)
## Final Submission ## Final Submission
...@@ -53,14 +31,14 @@ List your team members in the mail body. ...@@ -53,14 +31,14 @@ List your team members in the mail body.
- All unit tests succeed - All unit tests succeed
- All integration tests succeed - All integration tests succeed
- No memory is leaked - No memory is leaked
- Known issues must be present - Known issues is present and up-to-date
5. Run the following command: 5. Run the following command:
$ git archive --prefix=team_XX_final/ --format=zip HEAD > team_XX_final.zip $ git archive --prefix=team_XX_final/ --format=zip HEAD > team_XX_final.zip
6. Verify that the resulting archive contains everything you want to submit and nothing more. 6. Verify that the resulting archive contains everything you want to submit and nothing more.
7. Submit the zip archive via mail using the following line as subject (or link below). 7. Submit the archive via mail using the following line as subject (or link below).
703602 - Team XX Final 703602 - Team XX Final Submission
📧 [send email](mailto:alexander.hirsch@uibk.ac.at?subject=703602%20-%20Team%20XX%20Final) 📧 [send email](mailto:alexander.hirsch@uibk.ac.at?subject=703602%20-%20Team%20XX%20Final%20Submission)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment