conclusion.tex

   1 \section{Discussion \& Future Research}
   2 The system is still a crude prototype and a proof of concept. Improvements and
   3 extension for the system are amply available in several fields of study.
   4
   5 \subsection{Simulation}
   6 An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
   7 works in the same way as the existing \gls{C}-backed simulation. It simulates
   8 the bytecode interpretation. Moreover would be possible to let the simulator
   9 function as a real device, thus handling all communication through the
  10 existing \gls{SDS}-based systems and behave like a real device. At the moment
  11 the \emph{POSIX}-client is the reference client and contains debugging code.
  12 Adding a simulation view to the system allows for easy interactive debugging.
  13 However, it might not be easy to devise a simulation tool that accurately
  14 simulates the \gls{mTask} system accurately on some levels. The semantics can
  15 be simulated but timing and peripheral input/output are more difficult to
  16 simulate properly.
  17
  18 \subsection{Optimization}
  19 True multitasking could be added to the client software. This allows
  20 \gls{mTask}-\glspl{Task} to run truly parallel. All \glspl{mTask} get slices
  21 of execution time and will each have their own interpreter state instead of one
  22 system-wide one that is reset after am \gls{mTask} finishes. This does require
  23 separate stacks for each \gls{Task} and therefore increases the system
  24 requirements of the client software. However, it could be implemented as a
  25 compile-time option and exchanged during the handshake so that the server knows
  26 the multithreading capabilities of the client.
  27
  28 Hardly any work has been done in the interpreter. The current interpreter is a
  29 no nonsense stack machine. A lot of improvements can be done in this part. For
  30 example, precomputed \emph{gotos} can improve jumping to the correct part of
  31 the code corresponding to the correct instruction. Moreover, the stack
  32 currently consists of 16-bit values. All operations work on 16-bit values and
  33 this simplifies the interpreter implementation. A memory improvement can be
  34 made by converting the stack to 8-bit values. This does pose some problems
  35 since an equality instruction must work on single-byte booleans \emph{and}
  36 two-byte integers. Adding specialized instructions per word size could overcome
  37 this problem.
  38
  39 \subsection{Resources}
  40 Resource analysis during compilation can be useful to determine if an
  41 \gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
  42 not contain the correct peripherals --- such as an \gls{LCD} --- then the
  43 \gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
  44 given. It might even be possible to do this statically on the type level.
  45
  46 This idea could be extended to the analysis of stack size and possibly
  47 communication bandwidth. With this functionality ever more reliable fail-over
  48 systems can be designed. When the system knows precise bounds it can
  49 allocate more \glspl{Task} on a device whilst staying within safe memory
  50 bounds. The resource allocation can be done at runtime within the backend
  51 itself or a general backend can be devices that can calculate the resources
  52 needed for a given \gls{mTask}. A specific \gls{mTask} cannot have multiple
  53 views at the same time due to the restrictions of class based shallow
  54 embedding. It might even be possible to encode the resource allocation in the
  55 type system itself using forms of dependant types.
  56
  57 \subsection{Functionality}
  58 More \gls{Task}-combinators --- already existing in the \gls{iTasks}-system ---
  59 could be added to the \gls{mTask}-system to allow for more fine-grained control
  60 flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the
  61 \gls{TOP} paradigm even more and makes programming \glspl{mTask} for
  62 \gls{TOP}-programmers more seamless. Some of the combinators require previously
  63 mentioned extension such as the parallel combinator. Others might be achieved
  64 using simple syntactic transformations.
  65
  66 Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
  67 the current system this type of logic has to take place server side. Adding
  68 this functionality to the bytecode-view allows greater flexibility, easier
  69 programming and less communication resources. Adding these semantics requires
  70 modifications to the client software and extensions to the communication
  71 protocol since relations between \glspl{Task} also need to be encoded and
  72 communicated.
  73
  74 \subsection{Robustness}
  75 The robustness of the system can be greatly improved. Devices that lose
  76 connection are in the current system not well supported. The device will stop
  77 functioning and have to be emptied for a reconnect. \Glspl{Task} residing on a
  78 device that disconnected should be kept on the server to allow a swift
  79 reconnect and restoration of the \glspl{Task}. This holds the same for the
  80 client software. The client drops all existing \glspl{Task} on a shutdown
  81 request. An extra specialization of the shutdown could be added that drops the
  82 connection but keeps the \glspl{Task} in memory. During the downtime the
  83 \glspl{Task} can still be executed but publications need to be delayed. If the
  84 same server connects to the client the delayed publications can be sent
  85 anyways.
  86
  87 Moreover, devices could send their current \glspl{Task} back at the
  88 server to synchronize it. This allows interchanging servers without
  89 interrupting the client. Allowing the client to send \glspl{Task} to the server
  90 is something to handle with care because it can easily cause high bandwidth
  91 usage.
  92
  93 \section{Conclusion}
  94 This thesis introduces a novel system for add \gls{IoT} functionality to
  95 the \gls{TOP} implementation \gls{iTasks}. A new view for the existing
  96 \gls{mTask}-\gls{EDSL} has been created which compiles the program
  97 into bytecode that can be interpreted by a client. Clients have
  98 been written for several microcontrollers and consumer architectures which can
  99 be connected through various means of communication such as serial port,
 100 bluetooth, wifi and wired network communication. The bytecode on the devices is
 101 interpreted using a stack machine and provides the programmer interfaces
 102 to the peripherals. The semantics of the \glspl{mTask} tries to resemble the
 103 \gls{iTasks} semantics as close as possible.
 104
 105 The host language has a very efficient compiler and code generator. Therefore,
 106 compiling \glspl{mTask} is also fast. Compiling \glspl{mTask} is nothing
 107 more than running some functions native to the host language.
 108
 109 The dynamic nature allows the microcontroller to be programmed once and used
 110 many times. The program memory of microcontrollers often guarantees around
 111 $10.000$ write or upload cycles and therefore existing techniques such as
 112 generating \gls{C} code are not usable for dynamic \gls{Task} environments.
 113 The dynamic nature also allows the programmer to design fail-over mechanisms.
 114 When a device is assigned a \gls{Task} but another device suddenly becomes
 115 unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
 116 the first device that possibly takes over some of the functionality of the
 117 broken device without needing to recompile the code.