X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.tex;h=3f0b3e5ae317657806f10e0d93c1dacd9bb9d5bf;hb=20ea9da4247313e4ce6e3a385e2975424c62ebfe;hp=1b2e533446c365eefae5e7e0dbcd2b32f3f0b76c;hpb=5fef9ca5f782e58aca5c019c71db675e16138b4d;p=msc-thesis1617.git diff --git a/conclusion.tex b/conclusion.tex index 1b2e533..3f0b3e5 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -1,137 +1,5 @@ \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 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} -\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 \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. - -\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 -\gls{mTask}-\gls{Task} should be rejected and feedback to the user must be -given. It might even be possible to do this statically on the type level. - -\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 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} -\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. - -\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 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 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. +\input{conclusion.discussion} \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 -another device that is also suitable for running the \gls{Task} without needing -to recompile the code. +\input{conclusion.conclusion}