COMP50007.3 - Advanced Laboratory 2 - The Wacc Compiler: Milestone 3 Extensions
Summary
The Wacc Compiler: Milestone 3 Extensions
COMP50007.3 - Advanced Laboratory 2 Department of Computing Imperial College London
For the final milestone of the Wacc project, you are expected to extend your compiler and/or the Wacc language with some new features. You are free to add any features you want to any aspect of the compiler, from the language specification to the code generation. This is your chance to implement some of the more exciting compiler features that you were exposed to during the lectures.
You will also need to write a short report on your Wacc project, to help you reflect on what you have achieved during this lab exercise.
Details
Recall the four stages of the compilation process:
-
(Optionally) Perform Lexical Analysis: splitting the input file into tokens (some parsing approaches omit this stage).
-
Perform Syntactic Analysis: parsing the tokens and creating a representation of the structure of the input file.
-
Perform Semantic Analysis: working out and ensuring the integrity of the meaning of the input file.
-
Generate Machine Code: synthesizing output in the target language, maintaining the semantic meaning of the input file.
At this point in the project, you should have a complete compiler for the Wacc language that can handle all three of these stages.
For this last milestone you need to pick some aspect(s) of your compiler to extend. Your extensions can cover any or all of the stages listed above, or could even be at the language level. We deliberately give you a great deal of freedom so that you can concentrate on something that interests you.
Submit by 19:00 on Friday 15th March 2024
1
What To Do:
1. Decide on what you want to work on for your Wacc compiler extension(s).
2. Implement your chosen extension(s) to your Wacc compiler.
3. Write a report that discusses your experiences during the Wacc project and describes your extensions and their implementation.
Compiler Extensions
There are many possible extensions to the Wacc lab and we recommend that you choose something that interests you. If you have been careful in designing your compiler, extensions should not be too difficult to incorporate. Over the following pages, we give some suggestions of possible extensions sorted by their expected level of difficulty.
The marks awarded for this milestone will not depend solely on the number and difficulty of the extensions attempted. We will also consider the functionality and correctness of your extensions, and the quality and clarity of their design. That is, it is just as important to ensure that all of your extensions are complete in their implementation, and well-designed, as it is to attempt something challenging.
We will automatically take your group size into account when determing your “Technical Challenge” mark, scaling up the marks for smaller groups. Additionally, we expect you to implement at least one extension per group member (of any difficulty), otherwise a cap will be applied to your “Functional- ity/Correctness” mark proportional to the number of extensions you have attempted (e.g. if a group of 4 attempt only 3 extensions, then they will not be able to score more than 3/4 * 10 = 7.5 marks for this criteria). This means that you cannot just implement one Easy extension and expect to score 10/10 for
“Functionality/Correctness” (unless you are working alone for this milestone of the project).
Note that we expect any language specification extension to be backed up by an implementation
of that extension. You are also welcome to propose your own extensions, but you should have these
approved by the lab organiser before beginning implementation to ensure that they are appropriate.
Note: Trivial Extensions Depending on the tooling you are using, some extensions may be consid- ered as trivial, so you should consider the work required to implement it: if using parsley for instance, we know that supporting the purely syntactic hexadecimal, octal, or binary literals are trivial – they only require turning on a single flag. As a result, doing these extensions as a parsley group is likely to be considered for only for a tiny amount of credit – as a rule of thumb, if you can do it by changing a handful of characters, it will probably not be worth anything! The exception to that would be that you designed your original system so well that adding an extension becomes very easy as a result of your work – this is perfectly fine, and encouraged! If in doubt, just ask us.
Note: Law of Diminishing Returns To reward groups that attempt the more challenging extensions, we impose a sub-linear mark reduction on each group’s “Technical Challenge” mark based on the number 𝑛 of easier (1-2 mark) extensions attempted. This reduction follows the number of non-triangular numbers ≤ 𝑛 sequence1, and can be computed directly as: 𝐿𝐷𝑅(𝑛) = 𝑛 − ⌊√2 ∗ 𝑛 + 1 − 12 ⌋. This means that you cannot just implement 10 Easy extensions and expect to score 10/10 for “Technical Challenge”.
1see https://oeis.org/A083920 for more details
2
Easy [approx. 1-2 marks each]
Binary, Octal and Hexadecimal Literals: Extend the Wacc language to support additional integer
literal formats other than just base 10.
Bitwise Operators: Extend the expressions of the Wacc language to include bitwise operators such as ‘&’, ‘|’ or ‘∼’. You will need to carefully consider the syntax and semantics of any new expressions you add to the language.
Statically-Sized Array Types: Extend the Wacc language so that arrays can also be given a static length. You should consider the interactions this has with other language features.
Void Types: Extend the Wacc language with the ‘void’ type to allow for the definition of functions that do not return a value. You will need to carefully consider the semantics of new and existing expressions for any new types you add to the language. You will also need to consider how this change will interact with the original function syntax requirement that the body of every function must end with either a ‘return’’ statement or an ‘exit’ statement.
Conditional Expressions: Extend the Wacc language by allowing ‘if’ expressions, which are like ‘if’ statements but can appear within expressions.
Additional Loop Control Statements: Extend the Wacc language with additional loop control statements, for example ‘for’, ‘do-while’, ‘break’ or ‘continue’ (there are many more). You will need to carefully consider the syntax and precise semantics of any new statements you add to the language. Consider how you can best re-use the existing parts of your compiler when designing this.
Additional Branching Statements: Extend the Wacc language with additional conditional branch- ing statements, for example ‘if’ statements without an ‘else’ branch or ‘switch’ statements. You will need to carefully consider the syntax and precise semantics of any new statements you add.
C-Style Macros: Extend the Wacc language to support the definition and use of C-style macros. You will need to carefully consider the syntax and precise semantics of any new statements you add to the language.
Short, Byte Integer Types: Extend the Wacc language to support multiple types of integer. The current Wacc integer type is effectively a 32-bit signed integer. You could extend the integer types to include the common formats of byte (8-bit), short (16-bit). You will need to carefully consider the semantics of new and existing expressions for any new types you add to the language.
Long types As above with short and byte types, you may consider adding a long type as well (64-bit). This has more challenge because arm32 is 32-bit, so more care is needed when working with this type.
Floating-point Types: Extend the Wacc language with single and/or double-precision floating-point data types. You will need to carefully consider the semantics of new and existing expressions for any new types you add to the language.
3
Unicode Characters: Extend the Wacc language to support additional character formats other than just ASCII (for example Unicode UTF-8 characters).
Improved String Handling: Extend the Wacc language with additional operations on strings, such as concatenation and substring inclusion tests. You will need to carefully consider the syntax and semantics of any new expressions you add to the language. You may wish to allow for indexing on strings as well, but you should be careful to ensure string literals remain immutable!
Side-effecting Expressions: Extend the expressions of the Wacc language to allow for side-effects. For example, adding ‘+=’, ‘++’, ‘x = 5’, etc... as valid expressions. You will need to carefully consider which side-effecting expressions you allow and the semantics of these expressions when composed with our expressions. Consider how you can best re-use the existing parts of your compiler.
Optimisation - Basic Constant Folding: Extend your Wacc compiler with optimisation techniques that evaluate constant expressions at compile-time rather than runtime. For example, the source code may include an operation such as ‘1 + 2’, which the compiler can evaluate to ‘3’ instead. Doing this extension at an easy level may involve operations on the ast: you should consider how the semantics of Wacc are preserved through optimisation.
Optimisation - Basic Control-Flow Optimisation: Extend your Wacc compiler with optimisation techniques that simplify the source code. For example, a conditional branch statement of the form if false then C1 else C2 can be simplified to C2, as we know the ‘then’ branch of the statement will never be executed. Similar techniques can be applied to while-loops and other statements as well.
System Calls: Extend the Wacc language with statements that access native OS system calls. You will need to carefully consider which calls to implement and how this might affect the portability of your code.
Local Type Inference: Extend your Wacc compiler with support for locally infered types: these are the return types of functions and the types of local variables at the definition-site (but not function arguments). You should carefully consider how to do error reporting for this.
C-Style Structures: Extend the Wacc language with C-style structures with fields. Recall that a C structure consists of fields of any names and types, but these types are monomorphic and not polymorphic. You will need to carefully consider how these fields are accessed and updated. You should also consider how your structs will be allocated and passed into and out of functions.
Imports/Inclusions: Extend the Wacc language so that source files can import/include other source files. This would allow you to define functions in one file and use them in another. You will need to carefully consider the syntax and semantics of file imports, and any affect this might have on compiling your assembly code.
Interpreter Build an interpreter for Wacc into your compiler, which allows you to execute programs directly without generating assembly. You may wish to try interpreting your frontend’s ast, or perhaps your backend’s ir.
4
Medium [approx. 2-4 marks each]
Standard Library: Extend the Wacc language with some meaningful pre-defined functions that can be used anywhere in the program. You should carefully consider what kinds of libraries will be most useful to users. Consider how best to make this functionality available to users.
Full Pair Types: Extend the Wacc language with a full nested typing for pairs that does not lose type information for nested pairs. You will need to carefully consider the semantics of new and existing expressions for any new types you add to the language.
Pointer Types: Extend the Wacc language with a C-style pointer type. You may also find it useful to provide an address operator (similar to ‘&’ in C) that returns the address of a variable. You will need to carefully consider the semantics of new and existing expressions for any new types you add to the language.
Safe Pair Types: Extend the Wacc language by closing the unsoundness loophole with pair types: to do this, track the “true” type of a pair as runtime information so that unsafe coercions as a result of nested pairs result in a type error at runtime. You should consider how to lift the “nested pair extraction” and “read into nested pair extraction” restrictions using your new mechanism.
Optimisation - Parallel Compilation: Extend your Wacc compiler with the ability to compile separate modules/components in parallel, for a shorter overall compilation time. This would obviously need to build on top of the ability to import or include other Wacc files. You should be able to demonstrate a performance improvement as a result.
Polymorphic Types: Extend the Wacc language with parametric polymorphism. That is, extend your complex types and functions so that they accept type parameters. For example, a list of integers could be declared as ‘list(int)’. There are many different ways of handling generic functions and structures, and you may wish to consider issues like boxing, erasure, and specialisation2. You will need to carefully consider the semantics of new and existing expressions for any new types you add to the language.
Stack Allocation of Pairs and Arrays: Extend your Wacc compiler to allow for pairs and arrays (or your own structures!) to be allocated on the stack as well as the heap. You should consider under what circumstances this would be legal. You should consider how to distinguish the difference at the syntactic level – how does a language like C++ do it?
Anonymous and/or Nested Functions: In addition to First-Class Functions, extend your Wacc compiler to allow for the definition of anonymous or nested functions within a function. At this level, you should be careful to ensure that these functions are closed, so that they do not capture variables from the enclosing scope (see the Hard extension Closures).
2The reference compiler deals with the generic nature of pairs via boxing: this is why the reference compiler pairs are always two full sized words. The Jvm languages use boxing and erasure, but C++ uses template specialisation.
5
Function Overloading: Extend the Wacc language with function overloading. That is, allow for multiple functions to have the same name, but accept different numbers/types of arguments or return values. Your compiler should be able to determine which function is most suitable, at compile-time, according to the static types of its arguments.
First-Class Functions: Extend the Wacc language with the ability to store functions in variables and pass them as arguments to functions. You will need to carefully consider how this affects both the syntax and semantics of the language, including how to represent the types of these functions.
Simple Classes: Extend the Wacc language to include classes (without inheritance). Classes are similar to structures, but they may also have methods. You should also consider encapsulation strategies.
Reference Counting: Implement a simple form of garbage collection via reference counting on heap objects. You will need to carefully consider how and when to update the reference counts and when you will reclaim the corresponding memory. You should be able to discuss the limitations of this approach.
Interactive Wacc repl or ide: Create an ide or interactive repl (Read-Eval-Print Loop) to aid programmers writing Wacc programs. You’ll want to think about the features that would be most useful to the end-users.
Optimisation - Inlining Extend your Wacc compiler so that it can perform heuristic-guided in- lining of function calls. You should be careful to consider what functions to inline and under what circumstances. Your compiler must be robust against very large functions.
Optimisation - Peephole: Extend your Wacc compiler with optimisation techniques that simplify the generated assembly code (e.g. peephole optimisations). Your compiler should be able to analyse your generated code and remove redundant instructions. For example, you may have a store instruction followed by a load instruction which target the same register from the same address. In this case the load instruction is redundant and can be removed.
∗ The “Law of Diminishing Returns” no longer applies below this point ∗
Pass-by-Reference and -Value: Further extend your Wacc compiler so that stack-allocated structures can be passed to to functions with by reference (pointer) or by copying it. You will need to carefully consider how this is represented in language syntax, and how stack objects will be passed into the arguments of the function – perhaps consider how C passes and returns structs by value!
Cross-Compiler: Extend your Wacc compiler with the ability to compile Wacc programs to an alternative target architecture (e.g. aarch64, x86-64, or RISC-V). You will need to think carefully about how to avoid code duplication in your code generator. Note, that llvm does not count towards this. Supporting more than one extra target will be worth more, but less than the initial extra target.
Optimisation - Control-Flow Analysis Extend your Wacc compiler will more fully-fledged control flow analysis that can simplify redudant indirect branches, remove dead-code, and otherwise improve the jumping and control structures of the program. You should consider how this interacts with other aspects of the optimisations you may be doing.
6
Local Static Analysis: Extend your Wacc compiler so that it performs static analysis to help catch normally runtime problems at compile-time, and ideally remove the associated runtime checks by just looking at the information within a function. This might be something like array-bound analysis to remove length checks, tracking the current resident type inside a pair to prevent unsound coercions, identifying division-by-zero, null pointer use, and so on. Such techniques will not be able to catch all issues: consider carefully what information you can determine at compile-time and when that information is made stale and therefore invalid.
Optimisation - Constant Propagation (and Folding): Extend your Wacc compiler with optimi- sation techniques that detect variables with fixed values. Your compiler should be able to spot, at compile-time, if a variable always has a constant value. You should replace such variables with their constant values and evaluate the resulting expressions were possible. This will involve more involved techniques such as liveness analysis. To take this further, you should be able to also simplify resulting expressions, potentially revealing more opportunities for propagation. For example, if you know that x is always 10 at a certain point in a program where ‘y = x + 5’, then you can simplify this to ‘y = 15’ and propagate y too.
Optimisation - Efficient Register Allocation: Extend your Wacc compiler with optimisation techniques that make efficient use of registers in the generated assembly code (e.g via graph colouring algorithms). Your compiler should try to minimise the use of the heap/stack, holding on to data in the registers where possible. You will need to carefully consider how your compiler keeps track of which registers are in use at each point in time.
Optimisation - Tail-Recursion Optimisation Extend your Wacc compiler so that it can optimise tail-recursive functions so that they act more like loops (like Scala’s @tailrec annotation ensures). You will not need to consider arbitrary tail-calls at this level, or mutually recursive functions.
Global Monomorphic Type Inference: Extend your Wacc compiler with type inference for function arguments as well as variables and return types. You should be able to deduce the types of a function from how it is used internally and externally (so long as you have not introduced true subtyping!). The types deducted here should all be monomorphic, which is to say known types like int, char, and so on.
Hard [approx. 4-6 marks each]
Debugging Symbols Extend your compiler with a flag that allows for the generation of debugging symbols into the assembly file: this will allow a tool (you may wish to specialise to gdb) to properly link the assembly back to the source file, including allowing for the tracking of variables and dumping a functions stack frame usefully. It should allow for the user of wacc to debug their own programs, as opposed to just a tool for the compiler-writer to debug their own errant code-generators.
Dynamically-Typed Variables: Change the Wacc language so that it is dynamically typed rather than statically typed. You will need to carefully consider how this will affect the syntax and semantics of the language. In particular, you will probably find that you have a lot more work to do at run-time.
7
Optimisation - Tail-Call Optimisation Extend your Wacc compiler so that it can optimise general tail-calls into jumps. You should carefully consider how to manage the different stack frame sizes between different functions and ensure that no stack-space is leaked from a tail-recursive set of functions.
Classes with Inheritance: Extend the Wacc language to include classes and a simple system of class inheritance. You will need to carefully consider what happens when the attributes/methods of a class are overwritten.
Exceptions: Extend the Wacc language with an exception handling system. You will need to care- fully consider the syntax for generating/catching excpetions and the semantics of caught/uncaught exceptions.
Managed Heap: Extend the Wacc language with a heap you have designed and manage yourself (as opposed to just using malloc and free): you may wish to set aside a large chunk in the data segment for this. You will need to consider how to track free locations in this heap, and may wish to consider how to avoid the issue of heap-fragmentation.
Concurrency: Extend the Wacc lanuage to allow for the creation of new threads. You will need to carefully consider the syntax for creating parallel threads and how these threads will share resources or pass messages. Some synchronisation methods may also be required.
Global Polymorphic Type Inference: Extend your Wacc compiler with type inference for function arguments as well as variables and return types. You should be able to deduce the types of a function from how it is used internally and externally (so long as you have not introduced true subtyping!). This level of inference should be able to assign the most general type to a function, leveraging polymorphic types, including for recursive functions.
Lazy Evaluation and Pass-by-Name/Need: Extend your Wacc compiler with functional concepts like laziness. You may want to support different kinds of laziness, such as by-name parameter passing, where the entire expression passed is evaluated every time it is used in the body (Scala’s =>A type), or Haskell’s by-need evaluation, which only computes each argument once on demand. You should be able to demonstrate the effect of the laziness with programs that pass around “bad values” like ‘1/0’. You should consider the interactions this may have with other language extensions. You may wish to consider local lazy values (hint: not variables!) with a by-need semantics. You may wish to look into thunks.
Closures and Partial Application: Generalise your existing implementation of First-Class Func- tions and Anonymous and/or Nested Functions so that they support free variables in the function, which can be captured from the defining context. You should ensure that such captured context is independent from the parent, such that there is no dependency on the parent’s stack frame (i.e. captures are by-value instead of by-reference and pointers are only heap-allocated). Your system should naturally be able to support partial application as a result; for an extra Easy extension, you could additionally support curried function definition syntax so that functions can be partially applied easily: consider the ease-of-use of def add(x: Int)(y: Int) = x + y compared with
def add(x: Int) = (y: Int) => x + yinScala,say. 8
Very Hard / Insane [approx. 6-10 marks each]
Garbage Collection: Extend the Wacc language with dynamic garbage collection on the heap. You
will need to carefully consider how you detect garbage and how you arrange for its collection.
Global Static Analysis: Extend your Wacc compiler with more advanced static analysis that attempts to perform more aggressive static analysis across the whole-program. It should be able to catch a wider range of issues by considering the interactions between multiple functions. You may find it helpful to introduce static annotations like @unaliased, @const, or @nonnull to allow the user to inject extra information into your system that can be verified within the function or at call-site – or even try and infer these properties from the function or callers themselves!
Classes with Advanced Features: Extend the Wacc language with a full class system, including multiple-inheritance, overriding, class constructors, factory constructors, etc... You will need to carefully consider the syntax and semantics of your additions to the language.
Stack-Capturing Closures: Instead of the limitation suggested in Closures and Partial Appli- cation, where a closure copies all captured variables, allow a closure to capture its parents values by reference. This is much more challenging in comparison, as you may need to break away from the “classic” model of a function-call stack to one where functions keep their local data and arguments on a heap-allocated environment record, to which a pointer is kept on the stack. Looking up a variable may require traversal down a linked-list of such records, and closures keep their parent’s environment records alive even after the parent returns. You would need to consider how to manage the memory of these records, as so not create memory leaks.
Advanced Meta-programming Support: As opposed to simple C-like macros, some language have support for full metaprogramming: this is where code can itself serve as a first-class value. Such languages usually require an Interpreter, as code of the language being compiled will need to be executed at compile-time to generate more code. One such, principled, model is known as Staging. Here, it is possible to construct ast fragments as values using quasi-quotations: for instance, the expression ‘[| 4 + 6 |]’3 of type ‘code(int)’ would represent the tree Add(IntLit(4), IntLit(6)). These code fragments can be combined using anti-quotes (also called splices): given qidx of type ‘code(int)’ and qarr of type ‘code(char[])’, the expression ‘[| $qarr[$qidx] |]’ would have type ‘code(char)’ and would represent an index operation: the types will need to have been checked. When a splice is found outside of a quote, this signals that the compiler should execute the Wacc code inside the splice at compile-time with the interpreter to produce an ast to include at this point. This mechanism is used to create very specialised code that can optimise in ways a general-purpose compiler cannot. The “hello world” example of staging, the staged power function, could look something like the code in Figure 1.
There are many different considerations to build a system like this, including whether the code you call during compile-time must be in a different file (requiring Imports), and ensuring that variables are only quoted when they are runtime variables and not compile-time ones. An exception to this rule is for
“liftable” values: for instance you should be able to quote a compile-time variable ‘x’ if it has type ‘int’, because it is easy to construct the corresponding ‘IntLit’ value. We would be impressed if a group can
3This is Template Haskell syntax, some languages, like Scala 3, choose a syntax like ‘’(4 + 6)’ instead.
9
begin
# computes x^n but on a statically known n
code(int) stagedPower(int n, code(int) qx) is if n == 0 then return [| 1 |] else
code(int) powerNMinus1 = call stagedPower(n-1, qx);
return [| $qx * $powerNMinus1 |] fi
end
# the definition of square will expand to `return x * (x * 1)' by recursive splicing
int square(int x) is return $(stagedPower(2, [|x|])) end end
Figure 1: Staged power example
implement this, even with restrictions such as no ‘code(code(int))’ values. If you want to discuss this in more detail, Jamie works with this kind of metaprogramming in his research.
Implement a Wacc compiler using Wacc: Write a compiler for the Wacc language in the Wacc language. Be aware that this is no easy task, and would likely incorporate many of the extensions listed above (such as generic types, classes with inheritance and a full C-style heap). We will, however, be very impressed if a group can manage this.
Implement a De-Compiler for Wacc: Write a de-compiler for the Wacc language: given an assembly file (perhaps generated from the reference compiler – even better if optimisations are turned on!), try and analyse the assembly to re-construct the high-level control structures of a Wacc program. We should be able to provide you with as-yet-unseen files during code-review and it should be able to recover a working program – even if information like variable names are lost. As an additional challenge, it would be good if it worked for other groups generated assembly, which is likely to be uniquely different.
Write an Operating System: Write a basic operating system in the Wacc language. Be aware that this is no easy task, and would likely incorporate many of the extensions listed above (such as concurrency, libraries and system calls). We will, however, be very impressed if a group can manage to implement this extension.
10
Project Report
Write a short report (five pages maximum) providing a summary of your project.
The main goal of writing your report is to promote reflection on your experiences during the Wacc
lab. Assessment will focus on the professionalism and analysis you are able to demonstrate. The report should be divided into 4 sections:
• The Final Product: An analysis and critical evaluation of the quality of the Wacc compiler you have built. You should consider both whether it meets the functional specification of the project and whether you judge that it forms a sound basis for future development. You may also wish to address the performance characteristics of your compiler.
• Project Management: An analysis of the organisation of your group and your use of project management tools (such as Git). You should describe how your group was structured, how you coordinated your work and detail any tools that helped/hindered your progress. You should also discuss what went well and what you would do differently if you were to do the lab again.
• Design Choices and Implementation Details: An analysis of the design choices that you made during the Wacc project, including your implementation language and tool choices (with justifications), and any interesting issues you had to overcome during the implementation of your compiler. You should discuss the design patterns you used when designing your code and why you chose to use them. You might also want to provide a system architecture diagram for you compiler to aid this discussion.
• BeyondtheSpecification:AnevaluationofyourextensionstoyourWacccompiler.Youshould describe all of the language extensions, optimisations or other aspects that you have added to your compiler, especially highlighting how these features can be accessed or viewed. You should also briefly discuss what future extensions you would add to your compiler if you had more time.
11
Submission
As you work, you should add, commit and push your changes to your Git repository. Your GitLab repository should contain all of the source code for your program. In particular you should ensure that this includes:
• Any files required to build your compiler,
• AMakefileintherootdirectorywhichbuildsthecompilerwhenmakeisrunonthecommand-line,
• A script compile in the root directory which runs your compiler when ./compile is run on the command-line.
Ideally, your extensions should not break the core behaviour of the Wacc language, or your compiler, although in some cases this may reasonably not be the case. We expect you to keep periodically testing your work on LabTS and we will discuss these tests as part of the final code review. If you know that certain tests will fail you should be prepared to tell us why during the code review.
The markers will be cloning your repository to evaluate the extensions you discuss in your project report. To be sure that we are looking at the correct version of your code you will need to submit a revision id to CATe for your final solution.
Prior to submission, you should check the state of your GitLab repository using the LabTS webpages at https://teaching.doc.ic.ac.uk/labts. If you click through to your WACC_<group> repository, and toggle to the Wacc Extensions Milestone, you will see a list of the different versions of your work that you have pushed. Next to each commit you will see a link to that commit on GitLab as well as a button to submit that version of your code to Scientia.
You should submit to Scientia the version of your code that you consdier to be “final”. You can change this later by submitting a different version to Scientia. The submission button will be replaced with a confirmation message if the submission has been successful.
You should submit the chosen version of your code and your project report (report.pdf) to Scientia by 19:00 on Friday 15th March 2024.
Assessment
In total there are 50 marks available in this milestone. These are allocated as follows:
Compiler Extensions 25
Technical Challenge 10 Functionality/Correctness 10 Design Quality 5
Project Report 25
The Final Product 5 Project Management 5 Design Choices and Implementation Details 5 Beyond the Specification 5 Clarity and Presentation 5
This milestone will constitute 20% of the marks for the Wacc Compiler exercise. Your work will be assessed by an interactive code review session in the week beginning on Monday 18th March, where personalised feedback will be given to your group.
