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.
|
||||
|
||||
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.
|
||||
|
||||
|
@ -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`).
|
||||
3. **Control flow graph**
|
||||
- Valid inputs are convert to IR.
|
||||
- The IR can be printed (see `mc_ir`)
|
||||
- The CFG is generated and can be printed in the DOT format.
|
||||
- The IR can be printed (see `mc_ir`).
|
||||
- The CFG is generated and can be printed in the DOT format (see `mc_cfg_to_dot`).
|
||||
4. **Back-end**
|
||||
- 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.
|
||||
5. **Build Infrastructure**
|
||||
- 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 optional parts (0 or 1)
|
||||
- `{ }` 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 [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
|
||||
|
||||
`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.
|
||||
|
||||
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
|
||||
|
||||
@ -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] */
|
||||
|
||||
#### Call by Value
|
||||
|
||||
Function arguments are always passed by value.
|
||||
#### Call by Value / Call by Reference
|
||||
|
||||
`bool`, `int`, and `float` are passed directly.
|
||||
Strings and arrays are passed via pointers internally.
|
||||
|
||||
Modifications to an array done inside a function are visible outside of that function.
|
||||
|
||||
#### Type Conversion
|
||||
|
||||
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`.
|
||||
|
||||
*Note:* If the need for explicit type conversion arises, additional built-ins will be added for this purpose.
|
||||
|
||||
#### 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.
|
||||
`main` takes no arguments and returns an `int`.
|
||||
While the parser happily accepts empty source files, a semantic check enforces the presence of a function named `main`.
|
||||
This function takes no arguments and returns an `int`.
|
||||
|
||||
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.
|
||||
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`.
|
||||
|
||||
Log messages do not overlap on multi-threaded execution.
|
||||
@ -301,14 +308,15 @@ Log messages do not overlap on multi-threaded execution.
|
||||
### Parser
|
||||
|
||||
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 ‘(’
|
||||
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
### 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.
|
||||
|
||||
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.
|
||||
|
||||
@ -430,7 +438,7 @@ This is the main compiler executable, sometimes referred to as *driver*.
|
||||
|
||||
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.
|
||||
|
||||
@ -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.
|
||||
|
||||
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.
|
||||
|
||||
@ -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.
|
||||
|
||||
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
|
||||
|
||||
@ -653,7 +661,7 @@ Architectural design and readability of your code will be judged.
|
||||
- Code should be readable and tell *what* is happening.
|
||||
- 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.
|
||||
- Use the following order for includes:
|
||||
- Use the following order for includes (separated by an empty line):
|
||||
- Corresponding header (`ast.c` → `ast.h`)
|
||||
- System headers
|
||||
- Other library headers
|
||||
|
@ -50,7 +50,7 @@ List your team members in the mail body.
|
||||
4. Ensure everything works.
|
||||
- Everything builds
|
||||
- No (unjustified) warnings
|
||||
- All unit test succeed
|
||||
- All unit tests succeed
|
||||
- All integration tests succeed
|
||||
- No memory is leaked
|
||||
- Known issues must be present
|
||||
|
Loading…
Reference in New Issue
Block a user