Add some stuff about pipelining (unfinished).

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

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index 2782eee0958bb745c322ae681d646b8234eb2155..531e580284f9136cd75de713f0a0c8794bd28cb3 100644 (file)
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -137,7 +137,25 @@ 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.
+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}
@@ -163,6 +181,7 @@ 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
@@ -171,5 +190,19 @@ 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
+but I will highlight the most important challenges and tradeoffs.
+
+In general, the most important tradeoff seems to be between flexibility and
+everything else (code size, performance, complexity). This flexibility is
+expressed in which instructions are possible, which connections are present, how
+big register files are, etc.
+
+An important reason to be flexible is for programmability. If the hardware is
+regular, making a compiler that produces optimal code gets a lot easier.
+
+Code compression.
+
+I'll also
 spend a few words on the observed merits of hardware/software codesign.
+
+