* Add a few stub sections.

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

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index ca33370d7be489528e05be2e1288de9050704c19..fecab593a4d5000f70f2a3a6cb7a4a5520165007 100644 (file)
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -85,3 +85,30 @@ 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.
+
+\subsection{Familiarizing with LLVM}
+This section says something about integrating in the LLVM community as well as
+getting acquainted with the code.
+
+\subsection{Coding}
+This section says something about the challenges encountered while actually
+writing code, if I can think of enough things to say here.
+
+\subsection{Working together}
+This section says something about working with colleagues in various ways.
+
+\subsection{Staying generic}
+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).
+
+\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.