Commit 666a1860 authored by Alexander Hirsch's avatar Alexander Hirsch
Browse files

Update course information for next semester

parent 21a5b2cd
......@@ -2,28 +2,26 @@
| Date | Topic / Recommended Schedule / Deadlines |
| ---------- | ----------------------------------------- |
| 2020-03-03 | *no proseminar* |
| 2020-03-10 | Lexer complete |
| 2020-03-17 | |
| 2020-03-24 | |
| 2020-03-31 | Parser complete |
| 2020-04-07 | |
| 2020-04-14 | |
| 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) |
| 2021-03-05 | *Introduction* |
| 2021-03-12 | *Explaining lexer & parser code* |
| 2021-03-19 | Lexer complete |
| 2021-03-26 | |
| 2021-04-16 | Parser complete |
| 2021-04-23 | |
| 2021-04-30 | Semantic checks complete |
| 2021-05-07 | |
| 2021-05-14 | AST → TAC conversion complete |
| 2021-05-21 | |
| 2021-05-28 | TAC → ASM (no function calls) complete |
| 2021-06-04 | |
| 2021-06-11 | TAC → ASM (with function calls) complete |
| 2021-06-18 | CFG generation complete |
| 2021-06-25 | Build Test Submission deadline |
| 2021-07-16 | Final Submission deadline (no extensions) |
- [mC Compiler Specification](specification.md)
- [Getting Started Code-base](https://git.uibk.ac.at/c7031162/mcc)
- [Submission Guideline](submission.md)
- [Submission Guidelines](submission.md)
## Structure
......@@ -32,15 +30,16 @@ The ultimate goal of this course is to build a working compiler according to the
You are not allowed to use code from other people participating in this course or code that has been submitted previously by somebody else.
A *getting started* code-base is provided, but you can also start from scratch.
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.
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.
You may work together in teams of 1–3 people.
Teams may span across pro-seminar groups.
Teams may span across proseminar groups.
The proseminar takes place online [over at Twitch](https://www.twitch.tv/AlexWarhawk), attendance is not mandatory.
I recommend sending me snapshots of your code-base, I'll provide feedback on stream.
Please follow the submission guidelines.
### Programming Language
......@@ -54,37 +53,18 @@ Any of the following programming languages can be used:
Go easy on external dependencies and obscure language extensions — yes, I'm looking at you, Haskell.
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
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.
The submitted code has to compile and run on this system.
Using overly complex or cryptic concepts may negatively impact the evaluation process — again, looking at you, Haskell and your voodoo magic lenses.
## 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.
The final grade is computed solely from the final submission.
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.
### Remote Seminar
While university grounds are locked down, no attendance is required and no QA sessions are held.
I'll stream during the regular seminar times [over at Twitch](https://www.twitch.tv/AlexWarhawk), feel free to tune in and ask questions.
Streams should be recorded by Twitch automatically and remain online for 14 days.
I recommend sending me snapshots of your code-base, I'll provide feedback while streaming.
See [Submission Guideline](submission.md).
## Contacting Me
If you have questions or want to know more about a certain topic, I am always glad to help.
You can contact me by email, just be sure to send it from your university account.
Please keep your email informal and include the course number in the subject.
Preferably use the following link.
Just message me on Discord if you need anything.
Alternatively, you can send me an email using the following link.
📧 [send email](mailto:alexander.hirsch@uibk.ac.at?subject=703602%20-%20)
......@@ -54,3 +54,9 @@ Furthermore, the control flow graph is an essential tool used by optimising comp
- 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.
## Evaluation System
I'll be using a virtualised, updated Ubuntu 20.10 (64 bit) to examine your submissions.
From this you can infer the software versions I'll be using.
The submitted code has to compile and run on this system.
% Compiler Construction
% Alex Hirsch
% 3 March 2020
% 5 March 2021
# This ProSeminar
# This Proseminar
## Curriculum
> […] development of a compiler for a simple procedural programming language
> […] development of a compiler for a simple, procedural programming language
<aside class="notes">
As stated by the curriculum, your task is to build a simple compiler for a small procedural programming language.
......@@ -20,16 +20,12 @@ Still, it is highly recommended to work in teams and that you start early - alwa
- This is a master's course!
- Brain
If you struggle too much, do this course at a later time.
You can unregister until the end of April.
<aside class="notes">
By now, this course is notorious for requiring a lot of effort.
The legends are true; I am indeed expecting a decent level of skill from all of you.
This is a master's course after all.
While I don't care whether you have officially finished your bachelor, you should only take this course if you are certain that you meet the prerequisites.
Otherwise, skip it for now and come back to it when you have acquired the necessary knowledge.
</aside>
- - -
......@@ -50,7 +46,7 @@ Otherwise, skip it for now and come back to it when you have acquired the necess
Since this course is very programming intensive, you need to be fluent in one of these languages.
If choose C and think strings are compared using `==` you'll have a very hard time.
For OS, if you think calling `exec` without `fork` while implementing a library is a good idea, maybe revisit the corresponding lecture would be a good idea.
For OS, if you think calling `exec` without `fork` while implementing a library is a good idea, maybe revisiting the OS course would be a good idea.
</aside>
- - -
......@@ -85,23 +81,13 @@ The lecture and proseminar assumes that you are familiar with the basics of gram
- Specification provided
- Evaluation scheme provided
## In the Lab
- QA sessions
- I'll be present for questions
- You can work on your compiler
## Requirements
- Working compiler
- More positive than negative QA sessions
## Recommended Schedule
- March: lexer / parser
- April: semantic checks, start IR generation
- May: finish IR generation, start ASM generation
- June: finish ASM generation, CFG generation, polish
- See README
<aside class="notes">
You are free to deviate from this schedule.
......
......@@ -531,7 +531,7 @@ This is the main compiler executable, sometimes referred to as *driver*.
The following directory layout is used.
mcc/ # This node represents the root of the repository.
/ # This node represents the root of the repository.
├── app/ # Each C file in this directory corresponds to one executable.
│ ├── mc_ast_to_dot.c
│ ├── mcc.c
......@@ -599,7 +599,7 @@ Similarly, a way to run unit tests using `valgrind` is provided.
### Dependencies
The *prerequisites* section of the README enumerates all dependencies.
The implementation should not have any dependencies apart from the standard library, system libraries (POSIX), a testing framework, and a lexer / parser generator.
The implementation should not have any dependencies apart from the standard library, system libraries, a testing framework, and a lexer / parser generator.
If a dependency is not available via the evaluation system's package manager, it needs to be automatically built and used by the build system.
It is recommended to *vendor* such dependencies rather than downloading them during build time.
......@@ -611,7 +611,7 @@ Architectural design and readability of your code will be judged.
- Don't be a git — use [Git](https://git-scm.com/)!
- Files are UTF-8 encoded and use Unix line-endings (`\n`).
- Files contain *one* newline at the end.
- Lines do not contain trailing whitespaces.
- Lines do not contain trailing whitespace.
- Your code does not trigger warnings, justify them if otherwise.
- Do not waste time or space (this includes memory leaks).
- Check for leaks using `valgrind`, especially in error cases.
......@@ -624,7 +624,7 @@ Architectural design and readability of your code will be judged.
### C/C++
- While not required, it is highly recommended to use a formatting tool, like [ClangFormat](https://clang.llvm.org/docs/ClangFormat.html).
- Use [ClangFormat](https://clang.llvm.org/docs/ClangFormat.html).
A configuration file is provided in the getting started code-base; however, you are free to rule your own.
- Consider enabling address and memory sanitizers.
- Lines should not exceed 120 columns.
......
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