\subsection{Staying generic}
\label{StayingGeneric}
-This section says something about the challenge of writing generic code:
-(changes to) transformations that are useful for both LLVM (ie on regular
-architectures) as well as for Recore (on the Montium).
+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 clash of goals: The LLVM project aims for code that performs well on their
+supported architectures, while Recore aims for code that performs well (or more
+often, can compile at all) on 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 pass 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{Pipelined scheduling}
I've also been involved for a bit with the instruction scheduling algorithm