Actuall add the future work chapter (with content now).

diff --git a/Report/Main/Future.tex b/Report/Main/Future.tex
new file mode 100644 (file)
index 0000000..16c2a54
--- /dev/null
+++ b/Report/Main/Future.tex
@@ -0,0 +1,48 @@
+\chapter{Future work}
+This chapter will describe outstanding tasks and issues.
+
+\section{Verifiers}
+Currently, when faulty MontiumC is written, this will be detected very late in
+the process (usually only when the backend finds something it doesn't like).
+This means that it is quite hard to determine what is wrong in the input
+exactly, since the backend has only limited information about where code comes
+from.
+
+To greatly improve this situation, verifiers should be added to the frontend.
+These verifiers should verify the input and output code against
+the specifications. Apart from improving user feedback, this will also greatly
+help to fine tune the specifications and find bugs in the frontend.
+
+\section{Debug info preservation}
+Currently, transformation passes are mostly ignorant about debugging info, they
+treat it as ordinary code. Since debugging info is added to LLVM code by means
+of special function calls and transformations by default assume that an unknow
+function can do anything, this means that adding debug information can prevent
+transformations from happening. Making transformations aware of debugging info
+will allow them to perform transformations as normal, by updating or removing
+debugging info.
+
+These changes are generic for LLVM and not needed specifically for the Montium.
+Currently, most MontiumC code seems to still work even when some transformations
+are left out, but especially with the new hardware, some missed out
+optimizations might still be useful.
+
+\section{LLVM based backend}
+Currently, the frontend is using the LLVM framework, while the backend is
+completely separate. While this gives maximum flexibility to the backend, it
+might be useful to create a Montium backend within the LLVM framework. This
+backend would benefit from being able to use existing LLVM code and passes,
+utility code, etc. Also, this would enable the compiler to become a single
+binary executable, instead of having a seperate executable and a Java program.
+
+However, the main risk here is when the LLVM framework turns out to be not fully
+suitable for the Montium backend. When nothing can be reused, the amount of code
+needed is not any less, and if the framework poses limitations, might even be
+more. The new hardware design might be a lot more suitable for reusing code than
+the old Montium, though. Also, the added work of migrating to a new framework
+and new language is also a extra cost.
+
+Currently, doing this might or might not be a good idea. What is required first,
+is doing a more in-depth investigation of the LLVM backend framework (which is,
+unfortunately, the most under-documented part of LLVM) and perhaps a mockup
+implementation.