Add a small conclusion to the "What is MontiumC?" section.

[matthijs/projects/internship.git] / Report / Main / Problems / Challenges.tex

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index c70c087236bc9e3fe1bae02ba1ef6e54b91d5e77..e152393873c4ae8fc08b59bf874c693ce7723166 100644 (file)
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -83,7 +83,8 @@ anything is mappable, but with a simple compiler this 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
+Considering that our ideal is not reachable (Though the new hardware might take
+us a lot closer), every feature
 considered for MontiumC was 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
@@ -109,6 +110,20 @@ cannot all be mapped onto normal C operators. By using a specific
 function call for each, we can still distinguish between all the
 different operations and add extra arguments where needed.
 
+\subsubsection{What do we have now?}
+The result of this work is a usuable, but conservative, specification. It
+defines the subset of features that should certainly be supported. In practice,
+some other features will also work, but not reliably. Therefore, these are left
+out of the specification.
+
+It is not unlikely that the specification is still incorrect in a few places (or
+rather, that the code does not implement the specification properly). Since
+so far there has been not any automated checking of programs against the
+specification, these errors have not been uncovered. Once the new hardware is
+more clearly defined and the MontiumC specification is updated for it, this
+checking should be added so the specification and compiler can be better
+matched.
+
 \begin{figure}
        \caption{Low level MontiumC example}
 \label{ExampleLow}
@@ -176,8 +191,10 @@ written, but I can't really tell what's needed until I know how the code works,
 which I can't effectively learn without actively working with it, etc.) I
 started out with adapting the loop unrolling pass in LLVM to be better suited to
 the Montium architecture. Eventually, this code didn't turn out to be
-immediately useful (it's still not included currently), but it proved very
-insightful as to how the LLVM framework is built and what its possibilities are.
+immediately useful because deciding when to unroll a loop and when not to turned
+out rather hard (it's still not included currently). Working with this pass did
+prove very insightful, however, as to how the LLVM framework is built and what its
+possibilities are.
 
 Additionally, during my working with the code in this internship I also produced
 a number of patches for LLVM, containing bugfixes, some cleanup and
@@ -274,8 +291,8 @@ has flexibility that the compiler will never use, it's better to save
 area and complexity by making the hardware less flexible. Exactly for this
 reason, it is important to develop hardware and supporting software in parallel,
 instead of using the hardware first, software later approach used with the
-initial Montium (TODO: Is this true?). This allows for a much better balanced
-and usable design, without any unused extras.
+initial Montium. This allows for a much better balanced and usable design,
+without any unused extras.
 
 \subsubsection{Inner loop pipelining}
 When trying to improve runtime performance, the main focus is on