X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=406c744424fa53cfa552363c35a56a71f52fe201;hb=76254fbf2941fa0b5a02ab3a98104cad56959218;hp=6ee7e67cddf249b208b3d4e832d3b27be0f5b1f7;hpb=c4c4901bb58dcf6450dd50010e27be66f80b7a00;p=msc-thesis1617.git

diff --git a/conclusion.tex b/conclusion.tex
index 6ee7e67..406c744 100644
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -1,3 +1,74 @@
+\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.
+
+\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}
+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.
+
+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.
+
+\subsection{Resources}
+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 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}
+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 \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.
 \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
@@ -22,33 +93,3 @@ 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}
-
-\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.
-	\item Implement other classes from the \gls{mTask}-\gls{EDSL} such as the
-		\CI{mtask} class that allows tasks launching new tasks.
-\end{itemize}