conclusion.tex

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