-\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{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.
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
+be simulated but timing and peripheral input/output are more
difficult to simulate properly.
\subsection{Optimization}
\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?}
+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
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
+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} can not have multiple
+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
+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
+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.
+\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.
repositories / msc-thesis1617.git / blobdiff