X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=406c744424fa53cfa552363c35a56a71f52fe201;hb=c91e99cb9e71060f461c03d1454ad5f31e9495a1;hp=8d69ebcbfa98ace2a50f4419eb595589908b65ad;hpb=a3a00cd9df798eda92291a2f3f6c922bdfdfdac2;p=msc-thesis1617.git diff --git a/conclusion.tex b/conclusion.tex index 8d69ebc..406c744 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -1,5 +1,95 @@ -\section{Conclusion} - \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 +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.