Add a "What is MontiumC?" section.

diff --git a/Report/Main/Problem/Challenges.tex b/Report/Main/Problem/Challenges.tex
index 57a7e2ab63ff305a702bbe0cb1b58312872ba44d..ca33370d7be489528e05be2e1288de9050704c19 100644 (file)
--- a/Report/Main/Problem/Challenges.tex
+++ b/Report/Main/Problem/Challenges.tex
@@ -1,3 +1,87 @@
 \section{Challenges and Solutions}
 This section will describe the challenges faced during each of the tasks and the
 solutions found for both the task itself and the challenges.
 \section{Challenges and Solutions}
 This section will describe the challenges faced during each of the tasks and the
 solutions found for both the task itself and the challenges.

+
+\subsection{What is MontiumC?}
+A critical question popped up during at the beginning of my internship: What is
+MontiumC? Previously, there was no real specification of MontiumC. There was
+documentation about the functions that could be used, some examples and a lot of
+personal knowledge in the heads of the Recore employees, but ultimately MontiumC
+was "whatever the compiler eats".
+
+To be able to create a proper set of transformations, the constraints on the
+input and output of that transformation process should be properly specified.
+This entails two parts: Specifying the MontiumC language, and specifying the
+Montium IR constraints, which is is the input to the backend.
+
+Specifying Montium IR was relatively easy, since it is defined directly by the
+backend. The MontiumC specification is slightly more complex. There are two
+different angles to it: What does the compiler support, and what do we want the
+compiler to support.
+
+\subsubsection{What is supported?}
+One angle for looking at MontiumC is seeing what the compiler can currently
+compile and turn that into a formal specification. This approach works fine to
+set a baseline for the compiler: A point to start improving the transformations
+from. Apart from that, this initial specification is also useful in reviewing
+existing MontiumC code and verifying existing transformations.
+
+Existing MontiumC code is supported by the compiler (since it has been tweaked
+until it worked). However, the existing code might not fully work within the
+produced specification. This can happen in particular when existing code makes
+use of corner cases in the compiler that have been missed in (or left out of)
+the specification, because they will not work reliably in all cases.
+
+The best way to detect these cases is making the compiler check its input using
+an the specification. This way, any code operating outside of the specification
+can be detected automatically.
+
+Existing transformations, on the other hand, might miss a few corner cases. When
+writing the specification, a particular feature might appear supported by the
+compiler. On closer inspection, the transformation passes might miss some corner
+cases, which either need to be fixed or put into the specification.
+
+The best way to detect these cases is writing a lot of structured testing code,
+which uses (combinations of) the features that are supported according to the
+specification. This way, corner cases exposed by the testing code can be
+detected automatically.
+
+Building this initial specification did pose a number of challenges. Since
+simply trying all possible C features to see if they are accepted by the
+MontiumC compiler and thus valid MontiumC is a lengthy process and only useful
+in a limited way. A more constructive way would be to examine the compiler
+components to see what transformations are applied and from that derive the
+specification for valid MontiumC. However, most of these components are not very
+transparent. The Clang frontend supports a lot of C constructs and is not a
+trivial piece of code. It also has support for Objective C and partially C++,
+which makes it harder to see which code paths are actually used for compiling
+MontiumC. This issue is only partially solved, meaning that there might still be
+incorrect or missing cases in the specification.
+
+Another problem is the complexity of the C language. Although individual
+features can be described and supported with relative ease, combining features
+can easily lead to complex constructs which are hard to transform into supported
+Montium IR. This became more of an issue after adding features to the base
+specification of MontiumC, though.
+
+\subsubsection{What is wanted?}
+A completely different angle of looking at this, is from the requirements point
+of view. What do we want MontiumC to support? This angle is even harder than the
+previous one, since there are a lot of levels of requirements. Ideally, MontiumC
+would not exist and our compiler would support the C language fully. However,
+this would require a very complicated compiler (both frontend and backend).
+
+Not only that, it is simply not possible to map all valid C programs to the
+Montium hardware. "Regular" architectures don't suffer from this problem (as
+much), since most instruction sets are not fundamentally different from the
+features supported by C (or other imperative languages). This means that
+anything is mappable, but with a simple compiler will not result in the most
+efficient code. In the Montium case, a lot of things simply cannot be mapped on
+the hardware at all.
+
+Considering that our ideal is not reachable (by far), every feature in our
+wanted MontiumC should be evaluated thoroughly for feasibility, both in hardware
+and in the compiler. In practice, this meant that new language features would be
+informally expressed and discussed, and only added to the specification after
+being succesfully implemented. This is conforming to the incremental development
+of MontiumC that was envisioned at the outset of its development.