X-Git-Url: https://git.stderr.nl/gitweb?a=blobdiff_plain;f=Report%2FMain%2FConclusions.tex;h=4d2585ae6865c8f37bbe96a79aaa0b44acc8c41c;hb=a2f725352fd1fcd707a4e98b2b7bdc3298aa80a4;hp=34804964a3182a3a821bcf0cfc7322b5c785457e;hpb=99713a971023a195e42cf9e63a6b30e3e87d9880;p=matthijs%2Fprojects%2Finternship.git

diff --git a/Report/Main/Conclusions.tex b/Report/Main/Conclusions.tex
index 3480496..4d2585a 100644
--- a/Report/Main/Conclusions.tex
+++ b/Report/Main/Conclusions.tex
@@ -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. 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.
+
+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 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
+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. The people
+were cooperating, the job was fun yet challenging and the result is
+well-received.