-\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.
-
-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.
-
-The dynamic nature allows the microcontroller to be programmed once and used
-many times. The program memory of microcontrollers often guarantees around
-$10.000$ write or upload cycles and therefore existing techniques such as
-generating \gls{C} code are not usable for dynamic \gls{Task} environments.
-The dynamic nature also allows the programmer to design fail-over mechanisms.
-When a device is assigned a \gls{Task} but another device suddenly becomes
-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}
-\todo{class based shallow doesn't have multiple backend support}
-\todo{slow client software because of interpretation}
-\todo{What happens if a device dies? Task resending, add to handshake}
-
-
-\section{Future Research}
-The system is still crude and a proof of concept. Improvements and extension
-for the system are amply available in several fields of study.
+\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 real device. Thus handling all communication through the
+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 for example timing and peripheral input/output are more
-difficult to simulate properly.
+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 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.
+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.
-\todo{Parametric lenses on devices share?}
+\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
+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.
+given. It might even be possible to do this statically on the type level.
-This idea could be extended to the analysis of stack size and possibly
+\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 preciser 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} can not 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.
+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}
-More 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
+\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.
-Currently the \gls{C}-view allows tasks to launch other tasks. 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
+\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 tasks also need to be encoded and
+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 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,
+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
+$10.000$ write or upload cycles and therefore existing techniques such as
+generating \gls{C} code are not usable for dynamic \gls{Task} environments.
+The dynamic nature also allows the programmer to design fail-over mechanisms.
+When a device is assigned a \gls{Task} but another device suddenly becomes
+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.
repositories / msc-thesis1617.git / blobdiff