From: Matthijs Kooijman Date: Thu, 17 Jul 2008 12:17:27 +0000 (+0200) Subject: Rename Problem/ to Problems/ X-Git-Tag: Report-final~46 X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fprojects%2Finternship.git;a=commitdiff_plain;h=afb4f2c2a87c98277b03ee10943ef6061c86dbb5 Rename Problem/ to Problems/ --- diff --git a/Report/Main/Problem/Assignment.tex b/Report/Main/Problem/Assignment.tex deleted file mode 100644 index 3ae3cb9..0000000 --- a/Report/Main/Problem/Assignment.tex +++ /dev/null @@ -1,4 +0,0 @@ -\section{Assignment} -This section describes the original assignment and the tasks presented therein. -Since then a number of other tasks have surfaced and some tasks have changed, -those changes and new tasks have been included here. diff --git a/Report/Main/Problem/Challenges.tex b/Report/Main/Problem/Challenges.tex deleted file mode 100644 index ca33370..0000000 --- a/Report/Main/Problem/Challenges.tex +++ /dev/null @@ -1,87 +0,0 @@ -\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. diff --git a/Report/Main/Problems/Assignment.tex b/Report/Main/Problems/Assignment.tex new file mode 100644 index 0000000..3ae3cb9 --- /dev/null +++ b/Report/Main/Problems/Assignment.tex @@ -0,0 +1,4 @@ +\section{Assignment} +This section describes the original assignment and the tasks presented therein. +Since then a number of other tasks have surfaced and some tasks have changed, +those changes and new tasks have been included here. diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex new file mode 100644 index 0000000..ca33370 --- /dev/null +++ b/Report/Main/Problems/Challenges.tex @@ -0,0 +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.