Camil's comments: appendices

diff --git a/appendix-protocol.tex b/appendix-protocol.tex
index 523aabe..ad88ac4 100644 (file)
--- 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 (file)
--- 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.