X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=e493a5bf1471c92c92132cee51232b9d0679ac0d;hb=514965291a1999329cab3dd5f846a0ecce72cec7;hp=bde2501328f8656bd7d2669223650871c0eb88c2;hpb=e7aa975e1af0007783d9a100ca83ddd5c25d284b;p=msc-thesis1617.git diff --git a/conclusion.tex b/conclusion.tex index bde2501..e493a5b 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -1,94 +1,137 @@ -\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. +\section{Discussion \& Future Research} +The system is still a crude prototype 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 +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 -difficult to simulate properly. +be simulated but timing and peripheral input/output are more difficult to +simulate properly. \subsection{Optimization} +\paragraph{Multitasking on the client:} 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. +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?} +\paragraph{Optimizing the interpreter:} +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. Moreover, the stack +currently consists of 16-bit values. All operations work on 16-bit values and +this simplifies the interpreter implementation. A memory improvement can be +made by converting the stack to 8-bit values. This does pose some problems +since an equality instruction must work on single-byte booleans \emph{and} +two-byte integers. Adding specialized instructions per word size could overcome +this problem. \subsection{Resources} +\paragraph{Resource analysis: } 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 +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. +given. It might even be possible to do this statically on the type level. -This idea could be extended to the analysis of stack size and possibly +\paragraph{Extended resource analysis: } +The previous 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. +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 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 +\paragraph{Add more combinators: } +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 +\paragraph{Launch \glspl{Task} from a \gls{Task}: } +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. + +The \gls{SDS} functionality in the current system is bare. There is no easy way +of reusing a \gls{SDS} for another \gls{Task} on the same device or on another +device. Such functionality can be implemented in a crude way by tying the +\glspl{SDS} together in the \gls{iTasks} environment. However, this will result +in a slow updating system. Functionality for reusing shares from a device +should be added. This requires rethinking the storage because some typedness is +lost when the \gls{SDS} is stored after compilation. A possibility would be to +use runtime typing with \CI{Dynamic}s or the encoding technique currently used +for \CI{BCValue}s. Using \glspl{SDS} for multiple \glspl{Task} within one +device is solved when the previous point at paragraph~\ref{par:tasklaunch} is +implemented. + +\subsection{Robustness} +\paragraph{Reconnect with lost devices:} +The robustness of the system can be greatly improved. Devices that lose +connection are in the current system not well supported. The device will stop +functioning and have to be emptied for a reconnect. \Glspl{Task} residing on a +device that disconnected should be kept on the server to allow a swift +reconnect and restoration of the \glspl{Task}. This holds the same for the +client software. The client drops all existing \glspl{Task} on a shutdown +request. An extra specialization of the shutdown could be added that drops the +connection but keeps the \glspl{Task} in memory. During the downtime the +\glspl{Task} can still be executed but publications need to be delayed. If the +same server connects to the client the delayed publications can be sent +anyways. + +\paragraph{Reverse \gls{Task} sending:} +Moreover, devices could send their current \glspl{Task} back at the +server to synchronize it. This allows interchanging servers without +interrupting the client. Allowing the client to send \glspl{Task} to the server +is something to handle with care because it can easily cause high bandwidth +usage. + +\section{Conclusion} +This thesis introduces a novel system for add \gls{IoT} functionality to +the \gls{TOP} implementation \gls{iTasks}. A new view for the existing +\gls{mTask}-\gls{EDSL} has been created which compiles the program +into bytecode that can be interpreted by a client. Clients have +been written for several microcontrollers and consumer architectures which can +be connected through various means of communication such as serial port, +bluetooth, wifi and wired network communication. The bytecode on the devices is +interpreted using a 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, +compiling \glspl{mTask} is also fast. Compiling \glspl{mTask} is nothing +more than running some functions native to 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.