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
+the specification. This way, any code operating outside of the specification
can be detected automatically. Writing such checks has not happened yet, mainly
because the impact of the new hardware on MontiumC is not quite clear yet.
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
to make it run more efficiently.
In figure \ref{ExampleHigh} the same code is displayed, but this time
-using higer level C features (for loops, arra indexing). This is the
+using higer level C features (for loops, array indexing). This is the
level of code we are trying to achieve, but we're not there yet. It
should be noted that this is still not "normal" C, since we use the
"imul" function instead of the normal * operator. However, since the
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 usable, 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}
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
In some cases, these extra constraints can be formulated in a generic way, such
that the LLVM code can handle architectures with or without the constraint.
+Examples include providing Montium specific parameters through LLVM's
+``\verb TargetData '' class and modifications to the loop unroller to support
+custom policies.
+
In a lot of cases, however, the constraint is so Montium specific that changing
-LLVM to support it is not feasible. In a few cases, this meant that the backend
-was changed to support more features of the LLVM IR. In other cases, a
-Recore-specific transformations was added to solve these problems. In a few more
-cases, the problems are still unresolved, effectively resulting in additional
-constraints on the MontiumC language.
+LLVM to support it is not feasible.
+
+In a few of these cases, this meant that the backend was changed to support more
+features of the LLVM IR. An example of this is finding datapath constants (which
+are the result of a function in MontiumC, so hard to track by LLVM).
+
+In other cases, Recore-specific transformations were added to solve these
+problems. Examples of these are a transformation that removes all global
+variables and passes them as arguments and return values instead, a
+transformation that forcibly inlines all functions marked as ``\verb inline ''
+and a transformation that limits variable lifetimes by introducing extra phi
+nodes.
+
+In a few more cases, the problems are still unresolved, effectively resulting in
+additional constraints on the MontiumC language. Examples of these are
+preventing instructions from being moved out of if/else blocks (which is
+perfectly fine from an LLVM IR standpoint, but does not take into account the
+extra meaning that an if statement has in MontiumIR) and removal of unused bits
+from a constant (which could introduce more different constants than the Montium
+has registers for them).
+
\subsection{New hardware design}
\label{Pipelining}
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
projects / matthijs / projects / internship.git / blobdiff