Add a short piece about software pipelining.

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index ca33370d7be489528e05be2e1288de9050704c19..60a930e3babc391968a7aa54585993d0f1651ebb 100644 (file)
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -85,3 +85,14 @@ 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.
 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.

+
+\subsection{Pipelined scheduling}
+I've also been involved for a bit with the instruction scheduling algorithm
+required for the new (pipelined) hardware design. Even though this is completely
+outside of the area of my assignment, the initial prototype of that scheduler
+was created using LLVM by someone else, so I have been assisting him with that.
+Initially mostly helping out with hints on LLVM coding, but later also
+with thinking about the scheduler and hardware design.
+
+I will not go into much detail about the new hardware and its scheduler here,
+but I will highlight the most important challenges and tradeoffs.