X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=3f0b3e5ae317657806f10e0d93c1dacd9bb9d5bf;hb=20ea9da4247313e4ce6e3a385e2975424c62ebfe;hp=bde2501328f8656bd7d2669223650871c0eb88c2;hpb=e7aa975e1af0007783d9a100ca83ddd5c25d284b;p=msc-thesis1617.git

diff --git a/conclusion.tex b/conclusion.tex
index bde2501..3f0b3e5 100644
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -1,94 +1,5 @@
-\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 intepretation}
-\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 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.
+\section{Discussion \& Future Research}
+\input{conclusion.discussion}
 
-\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 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?}
-
-\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 more 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} 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.
-
-\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
-\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
-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
-communicated.
+\section{Conclusion}
+\input{conclusion.conclusion}