+To get a feeling for what MontiumC looks like, consider the fragment in
+figure \ref{ExampleLow}. This is a piece of code that reads values from
+one memory, multiplies them by two, and writes them back to another
+memory. As you can see, this is an awful lot of code. This has two main
+reasons. First, looping and memory indexing is very explicit and takes a
+lot of instructions. Second, the code is effectively software pipelined
+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
+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
+Montium defines a lot of different operations, most of which have a
+number of options (saturation, truncation, post shifting, etc.) these
+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.
+
+\begin{figure}
+ \caption{Low level MontiumC example}
+\label{ExampleLow}
+\begin{verbatim}
+mem input;
+mem output;
+word factor;
+
+void run(void) {
+ factor = from_int(2);
+ input = alloc_mem(P0M0);
+ output = alloc_mem(P0M1);
+ set_base(input, 0);
+ set_offset(input, 0);
+ set_base(output, -1);
+ set_offset(output, -1);
+
+ next_cycle();
+ word in = read_mem(input);
+ word out = p0o0(imul(ra1(in), rc1(factor)))
+ add_offset(input, 1);
+ add_offset(output, 1);
+ init_loop(LC1, 8);
+ do {
+ write_mem(output, out);
+ in = read_mem(input);
+ out = p0m0(imul(ra1(in), rc1(factor)))
+ add_offset(input, 1);
+ add_offset(output, 1);
+ } while(loop_next(LC1));
+
+ write_mem(output, out);
+\end{verbatim}
+\end{figure}
+
+\begin{figure}
+ \caption{High level MontiumC example}
+ \label{ExampleHigh}
+\begin{verbatim}
+P0M0 int input[10];
+P0M1 int output[10];
+
+void run(void) {
+ for (int i=0; i<10; ++i)
+ output[i] = mul(input[i], 2);
+}
+\end{verbatim}
+\end{figure}
+
+\subsection{Familiarizing with LLVM}
+Since the frontend heavily relies on the LLVM project for doing it's work, one
+of the first challenges was to get myself familiar with LLVM. There were two main
+aspects to this: Getting to know my way around the LLVM codebase and getting to
+know the LLVM community.
+
+LLVM has a pretty large amount of documentation, I spent most of my first
+weeks with reading tutorials and documents. Since there was already a (very
+preliminary) version of the clang-based frontend, I also had some code to play
+with.
+
+During this period, it was not completely clear what the frontend should
+be doing and what transformations should be written. To prevent circular
+dependencies in my tasks (I can't write any code before I know what needs to be
+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 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
+documentation improvements. Since the best way to integrate with any open source
+project seems to be contributing code, I was giving commit access to the LLVM
+tree not long thereafter. This access has proved very useful during the rest of
+the internship, since it was now a a lot easier to make (simple) changes to the
+LLVM framework to better suit the needs of Recore.
+
+A major challenge during my internship was to find the balance between doing
+work specifically for Recore, and doing work that is useful for LLVM in general.
+Any changes that are directly required by the Montium frontend and the LLVM changes they
+need are obvious. However, usually when making changes to the main LLVM
+tree, just changing enough for Recore is not engough for LLVM. Since the LLVM
+code must work on any program, not just MontiumC programs, extra changes are
+required (see also parapgrah \ref{StayingGeneric}). This is also an issue of
+building up credit within the LLVM community: The more you contribute to LLVM,
+the more influence you have when things need changing.
+
+Lastly, this is also a matter of efficiency: If I have been working
+with a particular piece of code intensively, it is more efficient for me to fix
+a bug in that code than most others, even though the particular bug does not
+interfere with the MontiumC frontend. In the end, I think I managed to find a
+decent balance, though it might have been tipped slighly in favour of the LLVM
+project.
+
+\subsection{Working together}
+Since the compiler plays a fairly central role in the development process at
+Recore, I have been cooperating with a number of different people, in different
+areas. On one end, the compiler is directly used by the DSP engineers, so a lot
+of the requirements and wishes for the compiler come from them. Also, they are
+often providing bug reports and other feedback, which ensures regular contact.
+
+On the other end, I have been in contact with the developer of the backend very
+intensively, since most changes made to either component needed changes in the
+other one as well. Compiler changes also require hardware support, so working
+with the hardware developers was not uncommon either. In practice, most
+communication with the hardware developers went through the backend
+developer, except for the design discussion concerning the new Montium
+hardware design (also see section \ref{Pipelining} below).
+
+In addition, discussions regarding design issues at various levels often happen
+out in the open, which invites people with an opinion about something to
+chime in, without the overhead of planning a seperate meeting for each
+topic. This allows for very quick feedback on ideas from people in all areas
+in an efficient way.
+
+\subsection{Staying generic}
+\label{StayingGeneric}
+The toughest challenge by far was to fit the features and changes required by
+Recore into code that is maintained by the LLVM project. The main problem here
+is a clash of goals: The LLVM project aims for code that performs well for their
+supported architectures, while Recore aims for code that performs well (or more
+often, can compile at all) for the Montium architecture.
+
+In general, these problems mainly occur because MontiumC and in particular
+MontiumIR poses a number of constraints that are not present in other
+architectures. This means that some transformations present in LLVM will violate
+these constraints (which would result in better code on most other
+architectures) resulting in miscompiled or uncompilable code.
+
+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.
+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.
+
+\subsection{New hardware design}
+\label{Pipelining}