Update course information for next semester
This commit is contained in:
parent
21a5b2cd61
commit
666a1860a7
74
README.md
74
README.md
@ -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.
|
||||
|
@ -1,12 +1,12 @@
|
||||
% 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.
|
||||
|
Loading…
Reference in New Issue
Block a user