X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=3f0b3e5ae317657806f10e0d93c1dacd9bb9d5bf;hb=8755061062b9738c80da1f5966c93ac6ec832a5c;hp=6c30c11abd362ef9ee148a96457ed2ed9fef7818;hpb=9eea8cc171594ce55c6b36135482df9cd5027627;p=msc-thesis1617.git

diff --git a/conclusion.tex b/conclusion.tex
index 6c30c11..3f0b3e5 100644
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -1,137 +1,5 @@
 \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, it 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 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 \gls{mTask}-\glspl{Task}
-get slices of execution time and will each have their own interpreter state
-instead of a single system-wide state which 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:}
-Due to time constraints and focus, 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 devised 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 \gls{mTask}-\glspl{Task} 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}: }\label{par:tasklaunch}
-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 on the 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 an \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 not well supported in the current system. The device will stop
-functioning and has 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.
+\input{conclusion.discussion}
 
 \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 for \gls{mTask} tries to resemble the
-\gls{iTasks} semantics as close as possible.
-
-The host language has a proven efficient compiler and code generator. Therefore,
-compiling \gls{mTask}-\glspl{Task} is also fast. Compiling an
-\gls{mTask}-\gls{Task} 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
-another device that is also suitable for running the \gls{Task} without needing
-to recompile the code.
+\input{conclusion.conclusion}