s/Twente University/University of Twente/ on the frontpage.
[matthijs/projects/internship.git] / Report / Main / Conclusions.tex
index 845d7b2e96d4fc07f0eabeaa7c400d593446e2ef..4d2585ae6865c8f37bbe96a79aaa0b44acc8c41c 100644 (file)
@@ -4,12 +4,12 @@ these lessons are very practical in nature (from how working in a company works
 to how to solve specific coding problems), there are also a number of higher
 level observations to be made.
 
-For example, I have found that the main challenge in solving a problem, is
+For example, I have found that the main challenge in creating solutions, is
 defining the actual problem you want to solve. This is clearly visible in the
 specification of MontiumC: If you don't know what the goals are, you can't
-really work towards them. But, on a smaller scale, this also holds on a smaller
-scale. When, during coding you encounter a problem, it's often easy to try to
-solve that problem. However, after stacking a few small solutions on top of each
+really work towards them. But this also holds on a smaller
+scale. When, during coding you encounter a problem, it's often easy to
+solve just that problem. However, after stacking a few small solutions on top of each
 other, things get complicated real fast. Then, it helps to take a step back and
 try to find the bigger problem you are trying to solve, and evaluate
 subsolutions in that perspective.
@@ -17,7 +17,7 @@ subsolutions in that perspective.
 During my (limited amount of) work with the new hardware design, it became
 quickly apparent that trying to design the hardware in an optimal way, was
 completely impossible (when trying to stay within area and power constraints).
-The most important issue in this design is finding the balance between two sides
+The most important issue here is finding the balance between two sides
 of a tradeoff, which was quite often hardware vs compiler complexity. Especially
 this last issue makes it very clear that when designing hardware, the supporting
 tooling should be designed in parallel, to prevent the tooling from needing to
@@ -25,11 +25,27 @@ be overly complex.
 
 These limitations are also visible when working with the old hardware: The
 hardware poses a lot of limitations on its input, which makes it quite hard to
-build a proper compiler, that can reliably compile anything that it is supposed
+build a proper compiler that can reliably compile anything that it is supposed
 to. Again, adapting the hardware to support the compiler, has the potential to
 make the compiler considerably less complex and more reliable, at the cost of
 larger hardware complexity, area and power consumption.
 
+However, when looking at the end result, I can conclude that the frontend has
+indeed improved a lot. Even though there are not as many features added to
+MontiumC as hoped, the existing features are more reliably supported now. The
+improvements in the frontend have allowed the backend to become simpler as
+well. Further improvement in this area is still possible, but there are a lot
+of things that the frontend simply cannot deal with, since it requires more
+hardware-specific knowledge or timing information, which the frontend does not
+have.
+
+Using the LLVM for developing the frontend has turned out to work quite well.
+It provides a lot of support code to simplify transforming of code. Also, the
+library-oriented architecture makes it easy to reuse (small) parts of the
+system, while leaving out other parts. In some cases the LLVM code is less
+suitable, but this is mostly solvable and should be less of an issue once the
+new hardware is finished.
+
 All in all, I feel that this internship has worked out quite well. The people
 were cooperating, the job was fun yet challenging and the result is
 well-received.