Rename Problem/ to Problems/

diff --git a/Report/Main/Problem/Assignment.tex b/Report/Main/Problem/Assignment.tex
deleted file mode 100644 (file)
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 (file)
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 (file)
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 (file)
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.