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}
+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
+writing code, if I can think of enough things to say here.
+
+\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. So compiler changes also require hardware support, so working
+with the hardware developers was not uncommon either. In practice, most of this
+communication 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 easily invites people with an opinion about something to
+chime in, without having to gather people around for every discussion that
+happens. 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 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}
+\label{Pipelining}
+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. I'll also
+spend a few words on the observed merits of hardware/software codesign.
projects / matthijs / projects / internship.git / blobdiff