From: Matthijs Kooijman Date: Tue, 8 Jul 2008 13:22:24 +0000 (+0200) Subject: Add a "What is MontiumC?" section. X-Git-Tag: Report-final~50 X-Git-Url: https://git.stderr.nl/gitweb?a=commitdiff_plain;h=c10489e2efb774c9f527c4a1c21c02bbf63bee85;p=matthijs%2Fprojects%2Finternship.git Add a "What is MontiumC?" section. --- diff --git a/Report/Main/Problem/Challenges.tex b/Report/Main/Problem/Challenges.tex index 57a7e2a..ca33370 100644 --- 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. + +\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.