From b8ed8189b345f81d7a91535959b3776593062535 Mon Sep 17 00:00:00 2001 From: Matthijs Kooijman Date: Mon, 28 Jul 2008 14:52:10 +0200 Subject: [PATCH] Actuall add the future work chapter (with content now). --- Report/Main/Future.tex | 48 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Report/Main/Future.tex diff --git a/Report/Main/Future.tex b/Report/Main/Future.tex new file mode 100644 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. -- 2.30.2