Fix misc style and spelling errors.
[matthijs/projects/internship.git] / Report / Main / Conclusions.tex
index 34804964a3182a3a821bcf0cfc7322b5c785457e..78b36b5c8b9bf8a340aac643977fcd6e3659d243 100644 (file)
@@ -1,2 +1,51 @@
 \chapter{Conclusions}
-This chapter will give a number of conclusions.
+During this internship, I have of course learned a lot. While a large part of
+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 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 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. 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.
+
+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 here is finding the balance between two sides
+of a tradeoff, which was quite often hardware versus 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
+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
+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.
+Cooperation with other employees was pleasant, the job was fun yet
+challenging and the result is well-received.