X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=49890e81b0d8b036c0d3f02d2284673390a1754b;hb=3b741caf91a50106d7321f6bb553f9249a7efb14;hp=94b75ff57c87dcd9a57accc8340b9fe51a4b251d;hpb=7ca87066ed1f3a962d993a9ac32ab761cfdc05a9;p=msc-thesis1617.git diff --git a/conclusion.tex b/conclusion.tex index 94b75ff..49890e8 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -1,94 +1,136 @@ -\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 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. +\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 +the bytecode interpretation. Moreover, it 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 for example timing and peripheral input/output are more -difficult to simulate properly. +simulates the \gls{mTask} system on some levels. The semantics can 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. +of execution time and will each have their own interpreter state instead of a +single system-wide state which 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. -\todo{Parametric lenses on devices share?} +\paragraph{Optimizing the interpreter:} +Due to time constraints and focus, 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 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. +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 devised 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 -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. +\paragraph{Launch \glspl{Task} from a \gls{Task}: }\label{par:tasklaunch} +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 on the 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. + +The \gls{SDS} functionality in the current system is bare. There is no easy way +of reusing an \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 not well supported in the current system. The device will stop +functioning and has 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 proven 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 +another device that is also suitable for running the \gls{Task} without needing +to recompile the code.