From 84c493802340455f6f3cc33cb2758fe4e443d8ee Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Mon, 26 Jun 2017 14:18:26 +0200 Subject: [PATCH] Camil's comments: appendices --- appendix-protocol.tex | 10 +++---- conclusion.tex | 67 +++++++++++++++++++++++-------------------- 2 files changed, 41 insertions(+), 36 deletions(-) diff --git a/appendix-protocol.tex b/appendix-protocol.tex index 523aabe..ad88ac4 100644 --- a/appendix-protocol.tex +++ b/appendix-protocol.tex @@ -34,7 +34,7 @@ interpreted as \gls{MSB} first integers. \end{table} \newpage -\section{mTasks} +\section{\gls{mTask}-\glspl{Task}} \begin{table}[H] \centering \begin{subfigure}[t]{.48\textwidth} @@ -45,8 +45,8 @@ interpreted as \gls{MSB} first integers. \midrule 1 & \texttt{'t'}\\ 2,3 & interval or interrupt\\ - 4,5 & length (\texttt{n})\\ - 6 to n+6 & bytecode\\ + 4,5 & length ($n$)\\ + 6 to $n$+6 & bytecode\\ \midrule\midrule \multicolumn{2}{c}{Response}\\ byte & value\\ @@ -89,14 +89,14 @@ interpreted as \gls{MSB} first integers. byte & meaning\\ \midrule 1 & \texttt{'s'}\\ - 2,3 & identifier\\ + 2,3 & id\\ 4,5 & value\\ \midrule\midrule \multicolumn{2}{c}{Response}\\ byte & meaning\\ \midrule 1 & \texttt{'s'}\\ - 2,3 & identifier\\ + 2,3 & id\\ \bottomrule \end{tabular} \caption{Send an SDS specification} diff --git a/conclusion.tex b/conclusion.tex index 6c30c11..aa79d52 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -5,14 +5,14 @@ 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, 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 on some levels. The semantics can be simulated -but timing and peripheral input/output are more difficult to simulate properly. +the bytecode interpretation. Moreover, it would also be possible to let the +simulator function as a real device, thus handling all communication through +the existing \gls{SDS}-based systems. 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 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:} @@ -23,7 +23,9 @@ 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. +the server knows the multithreading capabilities of the client. Multithreading +allows \glspl{Task} to be truly interruptable by other \glspl{Task}. +Furthermore, this allows for more fine-grained timing control of \glspl{Task}. \paragraph{Optimizing the interpreter:} Due to time constraints and focus, hardly any work has been done in the @@ -43,7 +45,10 @@ 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. +given. It might even be possible to do this statically on the type level. The +current system does not have any of this built-in. Sending a \gls{Task} that +uses the \gls{LCD} to a device not containing one will result in the device +just skipping the \gls{LCD} related instructions. \paragraph{Extended resource analysis: } The previous idea could be extended to the analysis of stack size and possibly @@ -67,7 +72,7 @@ flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the 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} +\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 on the server side. Adding this functionality to the bytecode-view allows greater flexibility, @@ -85,8 +90,7 @@ 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. +device is solved when the previous point is implemented. \subsection{Robustness} \paragraph{Reconnect with lost devices:} @@ -103,35 +107,36 @@ 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 +Furthermore, devices could send their current \glspl{Task} back to 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 +This thesis introduces a novel system for adding \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 for \gls{mTask} tries to resemble the +wifi and wired network communication. The bytecode on the devices is +interpreted using a stack machine and provides the programmer with interfaces +to the peripherals. The semantics for \gls{mTask} try to resemble the \gls{iTasks} semantics as close as possible. -The host language has a proven efficient compiler and code generator. Therefore, -compiling \gls{mTask}-\glspl{Task} is also fast. Compiling an -\gls{mTask}-\gls{Task} is nothing more than running some functions native to -the host language. +The host language has a proven efficient compiler and code generator. The +compilation is linear in the amount of instructions generated and is therefore +also scalable. Moreover, compiling \glspl{Task} is fast because it is nothing +more than running some functions native to the host language and there is no +intermediate \gls{AST}. -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. +The dynamic nature of the client 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 suitable 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. -- 2.20.1