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