uniformize the mTask/sds spelling

[msc-thesis1617.git] / conclusion.tex

diff --git a/conclusion.tex b/conclusion.tex
index 49890e8..6c30c11 100644 (file)
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -17,13 +17,13 @@ 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 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.
+\gls{mTask}-\glspl{Task} to run truly parallel. All \gls{mTask}-\glspl{Task}
+get slices 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.
 
 \paragraph{Optimizing the interpreter:}
 Due to time constraints and focus, hardly any work has been done in the
@@ -62,7 +62,7 @@ using forms of dependant types.
 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} paradigm even more and makes programming \gls{mTask}-\glspl{Task} 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.
@@ -118,12 +118,13 @@ 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
+to the peripherals. The semantics for \gls{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.
+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 dynamic nature allows the microcontroller to be programmed once and used
 many times. The program memory of microcontrollers often guarantees around