Minor adjustments and rewording
This commit is contained in:
parent
9fcf35a43d
commit
595489d8ab
@ -43,6 +43,8 @@ Your final grade is determined mostly by the final submission.
|
|||||||
A positive grade for your final submission is required to pass this course.
|
A positive grade for your final submission is required to pass this course.
|
||||||
|
|
||||||
In addition to this, I'll do short QA sessions during the course which influence your final grade.
|
In addition to this, I'll do short QA sessions during the course which influence your final grade.
|
||||||
|
For each QA session, you receive either a plus or a minus.
|
||||||
|
To pass this course, you need to have more pluses than minuses by the end of the semester.
|
||||||
|
|
||||||
Other submissions are not graded.
|
Other submissions are not graded.
|
||||||
|
|
||||||
|
@ -34,10 +34,11 @@ The mC compiler is implemented using modern C (or C++) adhering to the C11 (or C
|
|||||||
- Symbol tables can be viewed (see `mc_symbol_table`).
|
- Symbol tables can be viewed (see `mc_symbol_table`).
|
||||||
3. **Control flow graph**
|
3. **Control flow graph**
|
||||||
- Valid inputs are convert to IR.
|
- Valid inputs are convert to IR.
|
||||||
- The IR can be printed (see `mc_ir`)
|
- The IR can be printed (see `mc_ir`).
|
||||||
- The CFG is generated and can be printed in the DOT format.
|
- The CFG is generated and can be printed in the DOT format (see `mc_cfg_to_dot`).
|
||||||
4. **Back-end**
|
4. **Back-end**
|
||||||
- Valid inputs are converted to IR and then to assembly code.
|
- Valid inputs are converted to IR and then to assembly code.
|
||||||
|
- The assembly code can be printed (see `mc_asm`).
|
||||||
- GCC is invoked to create the final executable.
|
- GCC is invoked to create the final executable.
|
||||||
5. **Build Infrastructure**
|
5. **Build Infrastructure**
|
||||||
- Your code builds and tests successfully on my evaluation system.
|
- Your code builds and tests successfully on my evaluation system.
|
||||||
@ -57,7 +58,7 @@ The next segment presents the grammar of mC using this notation:
|
|||||||
- `( )` indicates grouping
|
- `( )` indicates grouping
|
||||||
- `[ ]` indicates optional parts (0 or 1)
|
- `[ ]` indicates optional parts (0 or 1)
|
||||||
- `{ }` indicates repetition (1 or more)
|
- `{ }` indicates repetition (1 or more)
|
||||||
- `[ ]` and `{ }` can be combined to build 0 or more repetition
|
- `[ ]` and `{ }` can be combined to build *0 or more* repetition
|
||||||
- `" "` indicates a terminal string
|
- `" "` indicates a terminal string
|
||||||
- `/ /` indicates a [RegEx](https://www.regular-expressions.info/)
|
- `/ /` indicates a [RegEx](https://www.regular-expressions.info/)
|
||||||
|
|
||||||
@ -164,10 +165,10 @@ Comments are discarded by the parser; however, line breaks are taken into accoun
|
|||||||
|
|
||||||
### Size Limitations
|
### Size Limitations
|
||||||
|
|
||||||
`long` and `double` is used in the compiler to store mC's `int` and `float` literals, respectively.
|
`long` and `double` are used in the compiler to store mC's `int` and `float` literals, respectively.
|
||||||
It is assumed that both types are big and precise enough to store the corresponding literal.
|
It is assumed that both types are big and precise enough to store the corresponding literal.
|
||||||
|
|
||||||
Furthermore, it is assumed that arrays are at most `LONG_MAX` bytes long.
|
Furthermore, it is assumed that arrays and strings are at most `LONG_MAX` elements long.
|
||||||
|
|
||||||
### Special Semantics
|
### Special Semantics
|
||||||
|
|
||||||
@ -216,25 +217,27 @@ Even further, one cannot assign to a variable of array type.
|
|||||||
|
|
||||||
c = a; /* not supported, even though both are of type int[10] */
|
c = a; /* not supported, even though both are of type int[10] */
|
||||||
|
|
||||||
#### Call by Value
|
#### Call by Value / Call by Reference
|
||||||
|
|
||||||
Function arguments are always passed by value.
|
|
||||||
|
|
||||||
`bool`, `int`, and `float` are passed directly.
|
`bool`, `int`, and `float` are passed directly.
|
||||||
Strings and arrays are passed via pointers internally.
|
Strings and arrays are passed via pointers internally.
|
||||||
|
|
||||||
|
Modifications to an array done inside a function are visible outside of that function.
|
||||||
|
|
||||||
#### Type Conversion
|
#### Type Conversion
|
||||||
|
|
||||||
There are *no* type conversion, neither implicit nor explicit.
|
There are *no* type conversion, neither implicit nor explicit.
|
||||||
|
|
||||||
An expression used as a condition (for `if` or `while`) is expected to be of type `bool`.
|
An expression used as a condition (for `if` or `while`) is expected to be of type `bool`.
|
||||||
|
|
||||||
|
*Note:* If the need for explicit type conversion arises, additional built-ins will be added for this purpose.
|
||||||
|
|
||||||
#### Entry Point
|
#### Entry Point
|
||||||
|
|
||||||
The top-level rule is `program` which simply consists of 0 or more function definitions.
|
The top-level grammar rule is `program` which simply consists of 0 or more function definitions.
|
||||||
|
|
||||||
While the parser happily accepts empty source files, a semantic check enforces that a function named `main` must be present.
|
While the parser happily accepts empty source files, a semantic check enforces the presence of a function named `main`.
|
||||||
`main` takes no arguments and returns an `int`.
|
This function takes no arguments and returns an `int`.
|
||||||
|
|
||||||
On success, an mC program returns `0`.
|
On success, an mC program returns `0`.
|
||||||
|
|
||||||
@ -294,6 +297,10 @@ For example, each semantic check may traverse the AST in isolation.
|
|||||||
Logging infrastructure may be present, however all log output is disabled by default.
|
Logging infrastructure may be present, however all log output is disabled by default.
|
||||||
The log level can be set with the environment variable `MCC_LOG_LEVEL`.
|
The log level can be set with the environment variable `MCC_LOG_LEVEL`.
|
||||||
|
|
||||||
|
0 = no logging
|
||||||
|
1 = normal logging (info)
|
||||||
|
2 = verbose logging (debug)
|
||||||
|
|
||||||
The output destination can be set with `MCC_LOG_FILE` and defaults to `stdout`.
|
The output destination can be set with `MCC_LOG_FILE` and defaults to `stdout`.
|
||||||
|
|
||||||
Log messages do not overlap on multi-threaded execution.
|
Log messages do not overlap on multi-threaded execution.
|
||||||
@ -301,14 +308,15 @@ Log messages do not overlap on multi-threaded execution.
|
|||||||
### Parser
|
### Parser
|
||||||
|
|
||||||
The parser reads the given input and, if it conforms syntactically to an mC program, constructs the corresponding AST.
|
The parser reads the given input and, if it conforms syntactically to an mC program, constructs the corresponding AST.
|
||||||
An invalid input is rejected, resulting in a meaningful error message, for instance:
|
An invalid input is rejected, resulting in a meaningful error message.
|
||||||
|
For instance:
|
||||||
|
|
||||||
foo.mc:3:8: error: unexpected '{', expected ‘(’
|
foo.mc:3:8: error: unexpected '{', expected ‘(’
|
||||||
|
|
||||||
It is recommended to closely follow the error message format of other compilers.
|
It is recommended to closely follow the error message format of other compilers.
|
||||||
This allows for better integration with IDEs.
|
This allows for better IDE integration.
|
||||||
|
|
||||||
Displaying the offending source line along with the error message is helpful, but not required.
|
Displaying the offending source code along with the error message is helpful, but not required.
|
||||||
|
|
||||||
Parsing may stop on the first error.
|
Parsing may stop on the first error.
|
||||||
Error recovery is optional.
|
Error recovery is optional.
|
||||||
@ -317,7 +325,7 @@ The parser component may be generated by tools like `flex` and `bison`, or simil
|
|||||||
Although, you are encouraged to implement a recursive descent or combinator parser instead.
|
Although, you are encouraged to implement a recursive descent or combinator parser instead.
|
||||||
Nevertheless, pay attention to operator precedence.
|
Nevertheless, pay attention to operator precedence.
|
||||||
|
|
||||||
Note that partial mC programs, like an expression or statement, are not valid inputs for the main *parse* function.
|
Note that partial mC programs, like an expression or statement, are not valid inputs to the main *parse* function.
|
||||||
The library may provide additional functions for parsing single expressions or statements.
|
The library may provide additional functions for parsing single expressions or statements.
|
||||||
|
|
||||||
### Abstract Syntax Tree
|
### Abstract Syntax Tree
|
||||||
@ -415,7 +423,7 @@ The applications are commonly defined by their usage information.
|
|||||||
Composing them with other command-line tools, like `dot`, is a core feature.
|
Composing them with other command-line tools, like `dot`, is a core feature.
|
||||||
|
|
||||||
The exact output format is not specified in all cases.
|
The exact output format is not specified in all cases.
|
||||||
However, details should *not* be omitted — like simplifying the AST>
|
However, details should *not* be omitted — like simplifying the AST.
|
||||||
|
|
||||||
All applications exit with code `EXIT_SUCCESS` iff they succeeded in their operation.
|
All applications exit with code `EXIT_SUCCESS` iff they succeeded in their operation.
|
||||||
|
|
||||||
@ -430,7 +438,7 @@ This is the main compiler executable, sometimes referred to as *driver*.
|
|||||||
|
|
||||||
usage: mcc [OPTIONS] file...
|
usage: mcc [OPTIONS] file...
|
||||||
|
|
||||||
The mC compiler. Takes mC input files and produes an executable.
|
The mC compiler. It takes mC input files and produces an executable.
|
||||||
|
|
||||||
Use '-' as input file to read from stdin.
|
Use '-' as input file to read from stdin.
|
||||||
|
|
||||||
@ -575,7 +583,7 @@ The README is kept short and clean with the following sections:
|
|||||||
`src` contains the implementation of the library, while `include` defines its API.
|
`src` contains the implementation of the library, while `include` defines its API.
|
||||||
|
|
||||||
Each application (C file inside `app`) is linked against the shared library and uses the provided interface.
|
Each application (C file inside `app`) is linked against the shared library and uses the provided interface.
|
||||||
They mainly contain argument parsing and combine the functionality provided by the library to achieve their task.
|
They mainly contain argument parsing and combine the functionality provided by the library to achieve their tasks.
|
||||||
|
|
||||||
The repository does not contain or track generated files.
|
The repository does not contain or track generated files.
|
||||||
|
|
||||||
@ -586,7 +594,7 @@ Under normal circumstances, all generated files are placed somewhere inside the
|
|||||||
At any point in time, the README contain a list of unfixed, known issues.
|
At any point in time, the README contain a list of unfixed, known issues.
|
||||||
|
|
||||||
Each entry is kept short and concise and should be justified.
|
Each entry is kept short and concise and should be justified.
|
||||||
Complex issues may reference a dedicated document inside `docs` providing more details.
|
More complex issues may reference a dedicated document inside `docs` providing more details.
|
||||||
|
|
||||||
## Build Infrastructure
|
## Build Infrastructure
|
||||||
|
|
||||||
@ -653,7 +661,7 @@ Architectural design and readability of your code will be judged.
|
|||||||
- Code should be readable and tell *what* is happening.
|
- Code should be readable and tell *what* is happening.
|
||||||
- A comment should tell you *why* something is happening, or what to look out for.
|
- A comment should tell you *why* something is happening, or what to look out for.
|
||||||
- An overview at the beginning of a module header is welcome.
|
- An overview at the beginning of a module header is welcome.
|
||||||
- Use the following order for includes:
|
- Use the following order for includes (separated by an empty line):
|
||||||
- Corresponding header (`ast.c` → `ast.h`)
|
- Corresponding header (`ast.c` → `ast.h`)
|
||||||
- System headers
|
- System headers
|
||||||
- Other library headers
|
- Other library headers
|
||||||
|
@ -50,7 +50,7 @@ List your team members in the mail body.
|
|||||||
4. Ensure everything works.
|
4. Ensure everything works.
|
||||||
- Everything builds
|
- Everything builds
|
||||||
- No (unjustified) warnings
|
- No (unjustified) warnings
|
||||||
- All unit test 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 must be present
|
||||||
|
Loading…
Reference in New Issue
Block a user