\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.
