X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=94b75ff57c87dcd9a57accc8340b9fe51a4b251d;hb=7694dfaa240c6dd9af2f1ac8880f0fb1d7f38324;hp=d94141a9b5059561775e881321092335d9fdb06b;hpb=aba35bf19efc06e7d771f2671a89032b7f20aeac;p=msc-thesis1617.git diff --git a/conclusion.tex b/conclusion.tex index d94141a..94b75ff 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -9,8 +9,8 @@ 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 the -\gls{mTask}-system is also relatively fast because the compilation of +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 @@ -19,35 +19,76 @@ $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 +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} -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. -\end{itemize} +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. + +\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 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. + +\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.