conclusion.tex

   1 \section{Conclusion}
   2 This thesis introduces a new view for the existing \gls{mTask}-\gls{EDSL}.
   3 The new view for the \gls{EDSL} compiles the language in to bytecode that can
   4 be interpreted by an \gls{mTask}-client. Clients have been written for several
   5 microcontrollers and consumer architectures that can be connected through
   6 various means of communication such as serial, bluetooth, wifi and wired
   7 network communication. The bytecode on the devices is interpreted using a
   8 simple stack machine and provides the programmer interfaces to the peripherals.
   9 The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
  10 as close as possible.
  11
  12 The host language has a very efficient compiler and code generator. Therefore,
  13 the \gls{mTask}-system is also relatively fast because the compilation of
  14 \glspl{mTask} is nothing more than running some functions in the host language.
  15
  16 The dynamic nature allows the microcontroller to be programmed once and used
  17 many times. The program memory of microcontrollers often guarantees around
  18 $10.000$ write or upload cycles and therefore existing techniques such as
  19 generating \gls{C} code are not usable for dynamic \gls{Task} environments.
  20 The dynamic nature also allows the programmer to design fail-over mechanisms.
  21 When a device is assigned a \gls{Task} but another device suddenly becomes
  22 unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
  23 the first device that possibly takes over some of the functionality of the
  24 broken device without needing to recompile the code.
  25
  26 \section{Discussion}
  27 \todo{class based shallow doesn't have multiple backend support}
  28 \todo{slow client software because of interpretation}
  29 \todo{What happens if a device dies? Task resending, add to handshake}
  30
  31
  32 \section{Future Research}
  33 The system is still crude and a proof of concept. Improvements and extension
  34 for the system are amply available in several fields of study.
  35
  36 \subsection{Simulation}
  37 An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
  38 works in the same way as the existing \gls{C}-backed simulation. It simulates
  39 the bytecode interpretation. Moreover would be possible to let the simulator
  40 function as real device. Thus handling all communication through the
  41 existing \gls{SDS}-based systems and behave like a real device. At the moment
  42 the \emph{POSIX}-client is the reference client and contains debugging code.
  43 Adding a simulation view to the system allows for easy interactive debugging.
  44 However, it might not be easy to devise a simulation tool that accurately
  45 simulates the \gls{mTask} system accurately on some levels. The semantics can
  46 be simulated but for example timing and peripheral input/output are more
  47 difficult to simulate properly.
  48
  49 \subsection{Optimization}
  50 True multitasking could be added to the client software. This allows
  51 \gls{mTask}-\glspl{Task} to run truly parallel. All \glspl{mTask} get slices
  52 of execution time and will each have their own interpreter state instead of one
  53 system-wide one that is reset after am \gls{mTask} finishes. This does require
  54 separate stacks for each task and therefore increases the system requirements
  55 of the client software. However, it could be implemented as a compile-time
  56 option and exchanged during the handshake so that the server knows the
  57 multithreading capabilities of the client.
  58
  59 \todo{Parametric lenses on devices share?}
  60
  61 \subsection{Resources}
  62 Resource analysis during compilation can be useful to determine if an
  63 \gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
  64 not contain the correct peripherals such as an \gls{LCD} then the
  65 \gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
  66 given.
  67
  68 This idea could be extended to the analysis of stack size and possibly
  69 communication bandwidth. With this functionality ever more reliable fail-over
  70 systems can be designed. When the system knows preciser bounds it can
  71 allocate more \glspl{Task} on a device whilst staying within safe memory
  72 bounds. The resource allocation can be done at runtime within the backend
  73 itself or a general backend can be devices that can calculate the resources
  74 needed for a given \gls{mTask}. A specific \gls{mTask} can not have multiple
  75 views at the same time due to the restrictions of class based shallow
  76 embedding. It might even be possible to encode the resource allocation in the
  77 type system itself using forms of dependant types.
  78
  79 \subsection{Functionality}
  80 More task-combinators already existing in the \gls{iTasks}-system could be added
  81 to the \gls{mTask}-system to allow for more fine-grained control flow between
  82 \gls{mTask}-\glspl{Task}. In this way the new system follows the \gls{TOP}
  83 paradigm even more and makes programming \glspl{mTask} for
  84 \gls{TOP}-programmers more seamless. Some of the combinators require previously
  85 mentioned extension such as the parallel combinator. Others might be achieved
  86 using simple syntactic transformations.
  87
  88 Currently the \gls{C}-view allows tasks to launch other tasks. In the current
  89 system this type of logic has to take place server side. Adding this
  90 functionality to the bytecode-view allows greater flexibility, easier
  91 programming and less communication resources. Adding these semantics requires
  92 modifications to the client software and extensions to the communication
  93 protocol since relations between tasks also need to be encoded and
  94 communicated.