+\section{Discussion \& Future Research}
+The system is still a crude prototype and a proof of concept. Improvements and
+extension for the system are amply available in several fields of study.
+
+\subsection{Simulation}
+An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
+works in the same way as the existing \gls{C}-backed simulation. It simulates
+the bytecode interpretation. Moreover would be possible to let the simulator
+function as a real device, thus handling all communication through the
+existing \gls{SDS}-based systems and behave like a real device. At the moment
+the \emph{POSIX}-client is the reference client and contains debugging code.
+Adding a simulation view to the system allows for easy interactive debugging.
+However, it might not be easy to devise a simulation tool that accurately
+simulates the \gls{mTask} system accurately on some levels. The semantics can
+be simulated but timing and peripheral input/output are more difficult to
+simulate properly.
+
+\subsection{Optimization}
+\paragraph{Multitasking on the client:}
+True multitasking could be added to the client software. This allows
+\gls{mTask}-\glspl{Task} to run truly parallel. All \glspl{mTask} get slices
+of execution time and will each have their own interpreter state instead of one
+system-wide one that is reset after am \gls{mTask} finishes. This does require
+separate stacks for each \gls{Task} and therefore increases the system
+requirements of the client software. However, it could be implemented as a
+compile-time option and exchanged during the handshake so that the server knows
+the multithreading capabilities of the client.
+
+\paragraph{Optimizing the interpreter:}
+Hardly any work has been done in the interpreter. The current interpreter is a
+no nonsense stack machine. A lot of improvements can be done in this part. For
+example, precomputed \emph{gotos} can improve jumping to the correct part of
+the code corresponding to the correct instruction. Moreover, the stack
+currently consists of 16-bit values. All operations work on 16-bit values and
+this simplifies the interpreter implementation. A memory improvement can be
+made by converting the stack to 8-bit values. This does pose some problems
+since an equality instruction must work on single-byte booleans \emph{and}
+two-byte integers. Adding specialized instructions per word size could overcome
+this problem.
+
+\subsection{Resources}
+\paragraph{Resource analysis: }
+Resource analysis during compilation can be useful to determine if an
+\gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
+not contain the correct peripherals --- such as an \gls{LCD} --- then the
+\gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
+given. It might even be possible to do this statically on the type level.
+
+\paragraph{Extended resource analysis: }
+The previous idea could be extended to the analysis of stack size and possibly
+communication bandwidth. With this functionality ever more reliable fail-over
+systems can be designed. When the system knows precise bounds it can allocate
+more \glspl{Task} on a device whilst staying within safe memory bounds. The
+resource allocation can be done at runtime within the backend itself or a
+general backend can be devices that can calculate the resources needed for a
+given \gls{mTask}. A specific \gls{mTask} cannot have multiple views at the
+same time due to the restrictions of class based shallow embedding. It might
+even be possible to encode the resource allocation in the type system itself
+using forms of dependant types.
+
+\subsection{Functionality}
+\paragraph{Add more combinators: }
+More \gls{Task}-combinators --- already existing in the \gls{iTasks}-system ---
+could be added to the \gls{mTask}-system to allow for more fine-grained control
+flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the
+\gls{TOP} paradigm even more and makes programming \glspl{mTask} for
+\gls{TOP}-programmers more seamless. Some of the combinators require previously
+mentioned extension such as the parallel combinator. Others might be achieved
+using simple syntactic transformations.
+
+\paragraph{Launch \glspl{Task} from a \gls{Task}: }
+Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
+the current system this type of logic has to take place server side. Adding
+this functionality to the bytecode-view allows greater flexibility, easier
+programming and less communication resources. Adding these semantics requires
+modifications to the client software and extensions to the communication
+protocol since relations between \glspl{Task} also need to be encoded and
+communicated.
+
+The \gls{SDS} functionality in the current system is bare. There is no easy way
+of reusing a \gls{SDS} for another \gls{Task} on the same device or on another
+device. Such functionality can be implemented in a crude way by tying the
+\glspl{SDS} together in the \gls{iTasks} environment. However, this will result
+in a slow updating system. Functionality for reusing shares from a device
+should be added. This requires rethinking the storage because some typedness is
+lost when the \gls{SDS} is stored after compilation. A possibility would be to
+use runtime typing with \CI{Dynamic}s or the encoding technique currently used
+for \CI{BCValue}s. Using \glspl{SDS} for multiple \glspl{Task} within one
+device is solved when the previous point at paragraph~\ref{par:tasklaunch} is
+implemented.
+
+\subsection{Robustness}
+\paragraph{Reconnect with lost devices:}
+The robustness of the system can be greatly improved. Devices that lose
+connection are in the current system not well supported. The device will stop
+functioning and have to be emptied for a reconnect. \Glspl{Task} residing on a
+device that disconnected should be kept on the server to allow a swift
+reconnect and restoration of the \glspl{Task}. This holds the same for the
+client software. The client drops all existing \glspl{Task} on a shutdown
+request. An extra specialization of the shutdown could be added that drops the
+connection but keeps the \glspl{Task} in memory. During the downtime the
+\glspl{Task} can still be executed but publications need to be delayed. If the
+same server connects to the client the delayed publications can be sent
+anyways.
+
+\paragraph{Reverse \gls{Task} sending:}
+Moreover, devices could send their current \glspl{Task} back at the
+server to synchronize it. This allows interchanging servers without
+interrupting the client. Allowing the client to send \glspl{Task} to the server
+is something to handle with care because it can easily cause high bandwidth
+usage.
+
\section{Conclusion}
-This thesis introduces a new view for the existing \gls{mTask}-\gls{EDSL}.
-The new view for the \gls{EDSL} compiles the language in to bytecode that can
-be interpreted by an \gls{mTask}-client. Clients have been written for several
-microcontrollers and consumer architectures that can be connected through
-various means of communication such as serial, bluetooth, wifi and wired
-network communication. The bytecode on the devices is interpreted using a
-simple stack machine and provides the programmer interfaces to the peripherals.
-The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
-as close as possible.
+This thesis introduces a novel system for add \gls{IoT} functionality to
+the \gls{TOP} implementation \gls{iTasks}. A new view for the existing
+\gls{mTask}-\gls{EDSL} has been created which compiles the program
+into bytecode that can be interpreted by a client. Clients have
+been written for several microcontrollers and consumer architectures which can
+be connected through various means of communication such as serial port,
+bluetooth, wifi and wired network communication. The bytecode on the devices is
+interpreted using a stack machine and provides the programmer interfaces
+to the peripherals. The semantics of the \glspl{mTask} tries to resemble the
+\gls{iTasks} semantics as close as possible.
The host language has a very efficient compiler and code generator. Therefore,
-the \gls{mTask}-system is also relatively fast because the compilation of
-\glspl{mTask} is nothing more than running some functions in the host language.
+compiling \glspl{mTask} is also fast. Compiling \glspl{mTask} is nothing
+more than running some functions native to the host language.
The dynamic nature allows the microcontroller to be programmed once and used
many times. The program memory of microcontrollers often guarantees around
unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
the first device that possibly takes over some of the functionality of the
broken device without needing to recompile the code.
-
-
-\section{Discussion}
-
-\section{Future Research}
-Future improvements of the system could be:
-\begin{itemize}
- \item Add an additional simulation view to the \gls{mTask}-\gls{EDSL} that
- simulates the bytecode interpreter and possibly functions as a full
- fledged device, thus handling all communication through the existing
- system.
- \item Add true multitasking to the client software allowing
- \gls{mTask}-\glspl{Task} to run truly parallel. This does require
- separate stacks for each task and therefore increases the system
- requirements of the client software. However, it could be implemented
- as a compile-time option and exchanged during the handshake so that the
- server knows the multithreading capabilities of the client.
- \item Resource analysis during compilation can be useful to determine if an
- \gls{mTask}-\gls{Task} is suitable for a specific device. If the device
- does not contain the correct peripherals such as an \gls{LCD} then the
- \gls{mTask}-\gls{Task} should be rejected and feedback to the user must
- be given. This could also be extended to minimum stack size needed to
- run the task and memory requirements for storing the \gls{Task}.
- \item Implement more \gls{Task} combinators such as the step combinator to
- allow for more fine-grained control flow between
- \gls{mTask}-\glspl{Task}. This could be extended to a similar system
- as in the \gls{C}-code generation view. The \glspl{Task} can launch
- other \glspl{Task} and compose \glspl{Task} of subtasks.
-\end{itemize}
repositories / msc-thesis1617.git / blobdiff