Report/Main/Future.tex

   1 \chapter{Future work}
   2 \label{FutureWork}
   3 This chapter will describe tasks for the future and issues that remain
   4 to be resolved.
   5
   6 \section{Verifiers}
   7 Currently, when faulty MontiumC is written, this will be detected very late in
   8 the process (usually only when the backend finds something it doesn't like).
   9 This means that it is quite hard to determine what is wrong in the input
  10 exactly, since the backend has only limited information about where code comes
  11 from.
  12
  13 To greatly improve this situation, verifiers should be added to the frontend.
  14 These verifiers should verify the input and output code against
  15 the specifications. Apart from improving user feedback, this will also greatly
  16 help to fine tune the specifications and find bugs in the frontend.
  17
  18 \section{Debug info preservation}
  19 \label{PreserveDebug}
  20 Currently, transformation passes are mostly ignorant about debugging info, they
  21 treat it as ordinary code. Debugging info is added to LLVM code by means
  22 of special function calls. Transformations by default assume that an unknown
  23 function can do anything, which means that adding debug information can prevent
  24 transformations from happening. Making transformations aware of debugging info
  25 will allow them to perform transformations as normal, by updating or removing
  26 debugging info.
  27
  28 Currently, the frontend supports the emission of debugging info, which
  29 the backend can use to improve it's error messages. To still perform all
  30 the needed optimizations, LLVM was patched to ignore debug info in a
  31 specific situation. This is not a long term solution, which requires
  32 more invasive changes to LLVM.
  33
  34 These changes are generic for LLVM and not needed specifically for the Montium.
  35 Currently, most MontiumC code seems to still work with only a little
  36 change to LLVM, but especially with the new hardware, these missed
  37 optimizations might become more of problem.
  38
  39 \section{LLVM based backend}
  40 Currently, the frontend is using the LLVM framework, while the backend is
  41 completely separate. While this gives maximum flexibility to the backend, it
  42 might be useful to create a Montium backend within the LLVM framework. This
  43 backend would benefit from being able to use existing LLVM code and passes,
  44 utility code, etc. Also, this would enable the compiler to become a single
  45 binary executable, instead of having a seperate executable and a Java program.
  46
  47 However, the main risk here is that the LLVM framework might turn out to be not fully
  48 suitable for the Montium backend. When nothing can be reused, the amount of code
  49 needed is not any less, and if the framework poses limitations, might even be
  50 more. The new hardware design might be a lot more suitable for reusing LLVM code than
  51 the old Montium, however. Also, the added work of migrating to a new framework
  52 and new language is also an extra cost.
  53
  54 Currently, doing this might or might not be a good idea. What is required first,
  55 is doing a more in-depth investigation of the LLVM backend framework (which is,
  56 unfortunately, the most under-documented part of LLVM) and perhaps a mockup
  57 implementation.