X-Git-Url: https://git.stderr.nl/gitweb?a=blobdiff_plain;f=Report%2FMain%2FProblems%2FChallenges.tex;h=2d85cf6ee41eb76f62b7211a68553ed98563c14c;hb=a0a6273b5d64a359ae4e341c3e928973c471c9e2;hp=fecab593a4d5000f70f2a3a6cb7a4a5520165007;hpb=c39d401495ea919a33b3a5206889823ed822cb69;p=matthijs%2Fprojects%2Finternship.git

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index fecab59..2d85cf6 100644
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -87,8 +87,50 @@ 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.
+Since during my internship I have been working mainly with LLVM (code), one of
+the first challenges was to get myself familiar with LLVM. There are two main
+aspects to this: Getting to know my way around the LLVM codebase and getting to
+know the LLVM community.
+
+Since 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 (it's still not included currently), but it proved very
+insightful as to how the LLVM framework is built and what its possibilities are.
+
+Additionally, during my working with the code in this stage 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 tasks that are required by the Montium frontend and the LLVM changes they
+directly need are obvious. However, usually when making changes to the main LLVM
+code, 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{Coding}
 This section says something about the challenges encountered while actually
@@ -98,6 +140,7 @@ writing code, if I can think of enough things to say here.
 This section says something about working with colleagues in various ways.
 
 \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).
@@ -111,4 +154,5 @@ 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.
+but I will highlight the most important challenges and tradeoffs. I'll also
+spend a few words on the observed merits of hardware/software codesign.