rephrase to remove overfull hbox

[msc-thesis1617.git] / arch.devices.tex

diff --git a/arch.devices.tex b/arch.devices.tex
index b43a40f..c06d964 100644 (file)
--- a/arch.devices.tex
+++ b/arch.devices.tex
@@ -2,19 +2,18 @@ A device is suitable for the system as a client if it can run the engine.
 The engine is compiled from one codebase and devices implement (part of) the
 device specific interface. The shared codebase only uses standard \gls{C} and
 no special libraries or tricks are used. Therefore, the code is compilable for
 The engine is compiled from one codebase and devices implement (part of) the
 device specific interface. The shared codebase only uses standard \gls{C} and
 no special libraries or tricks are used. Therefore, the code is compilable for

-almost any device or system. Note that it is not needed to implement a full
-interface. The full interface --- excluding the device specific settings --- is
-listed in Appendix~\ref{app:device-interface}. The interface works in a
-similar fashion as the \gls{EDSL}. Devices do not have to implement all
-functionality, this is analogous to the fact that views do not have to
-implement all type classes in the \gls{EDSL}. When the device connects with
-the server for the first time, the specifications of what is implemented is
-communicated. Devices must be available throughout sessions and cannot always
-be kept in scope and therefore they are stored in an \gls{SDS}.
+almost any device or system. The full interface --- excluding the device
+specific settings --- is listed in Appendix~\ref{app:device-interface}. The
+interface works in a similar fashion as the \gls{EDSL}. Devices do not have to
+implement all functionality, this is analogous to the fact that views do not
+have to implement all type classes in the \gls{EDSL}. When the device connects
+with the server for the first time, the specifications of what is implemented
+is communicated. Devices must be available throughout sessions and cannot
+always be kept in scope and therefore they are stored in an \gls{SDS}.

 
 At the time of writing the following device families are supported and can run
 the device software. Porting the client software to a new device does not
 
 At the time of writing the following device families are supported and can run
 the device software. Porting the client software to a new device does not

-require a lot of work. For example, porting to the \texttt{mbed} device family
+require a lot of work. For example, porting to the \gls{mbed} device family

 only took about an hour.
 \begin{itemize}
        \item \texttt{POSIX} compatible systems connected via the \gls{TCP}.
 only took about an hour.
 \begin{itemize}
        \item \texttt{POSIX} compatible systems connected via the \gls{TCP}.


@@ -22,7 +21,7 @@ only took about an hour.
                This port only uses functionality from the standard \gls{C} library and
                therefore runs on \emph{Linux} and \emph{MacOS}.
        \item Microcontrollers supported by the
                This port only uses functionality from the standard \gls{C} library and
                therefore runs on \emph{Linux} and \emph{MacOS}.
        \item Microcontrollers supported by the

-               \texttt{mbed}\footnote{\url{https://mbed.com}} environment.
+               \gls{mbed}\footnote{\url{https://mbed.com}} environment.

 
                This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
                development board.
 
                This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
                development board.


@@ -41,8 +40,8 @@ only took about an hour.
                client has been made for the \texttt{ESP8266} powered \emph{NodeMCU}
                that is connected via \gls{TCP} over WiFi. A port also has been made
                for the regular \gls{Arduino} \emph{Uno} board which only boasts a
                client has been made for the \texttt{ESP8266} powered \emph{NodeMCU}
                that is connected via \gls{TCP} over WiFi. A port also has been made
                for the regular \gls{Arduino} \emph{Uno} board which only boasts a

-               meager \emph{2K} \emph{RAM}. The stack size and storage available for
-               devices boasting this little \emph{RAM} has to be smaller than default
+               meager \emph{2KB} RAM. The stack size and storage available % chktex 13
+               for devices boasting this little RAM has to be smaller than default

                but are still suitable to hold a hand full of \glspl{Task}.
 \end{itemize}
 
                but are still suitable to hold a hand full of \glspl{Task}.
 \end{itemize}
 


@@ -114,11 +113,11 @@ memory space are reordered in such a way that there are no holes left. In
 practice this means that if the first received \gls{Task} is removed, all
 \glspl{Task} received later will have to move back. Obviously, this is quite
 time intensive but it can not be permitted to leave holes in the memory since
 practice this means that if the first received \gls{Task} is removed, all
 \glspl{Task} received later will have to move back. Obviously, this is quite
 time intensive but it can not be permitted to leave holes in the memory since

-the memory space is so limited. This techniques allows for even the smallest
-tested microcontrollers with only $2K$ \emph{RAM} to hold several \glspl{Task}
-and \glspl{SDS}. Without this technique, the memory space will decrease over
-time and the client can then not run for very long since holes are evidently
-created at some point.
+the memory space is so limited. With this technique, even the smallest
+tested microcontrollers with only $2K$ RAM can hold several \glspl{Task} and
+\glspl{SDS}. Without this technique, the memory space will decrease over time
+and the client can then not run for very long since holes are evidently created
+at some point.

 
 The structure instances and helper functions for traversing for \glspl{Task}
 and \glspl{SDS} are shown in Listing~\ref{lst:structs}.
 
 The structure instances and helper functions for traversing for \glspl{Task}
 and \glspl{SDS} are shown in Listing~\ref{lst:structs}.


@@ -182,12 +181,12 @@ void run_task(struct task *t){
                        pc+=2;
                        break;
                // ...
                        pc+=2;
                        break;
                // ...

-               case BCADD: trace("add");
+               case BCADD:

                        stack[sp-2] = stack[sp-2] + stack[sp-1];
                        sp -= 1;
                        break;
                // ...
                        stack[sp-2] = stack[sp-2] + stack[sp-1];
                        sp -= 1;
                        break;
                // ...

-               case BCJMPT: trace("jmpt to %d", program[pc]);
+               case BCJMPT:

                        pc = stack[--sp] ? program[pc]-1 : pc+1;
                        break;
                // ...
                        pc = stack[--sp] ? program[pc]-1 : pc+1;
                        break;
                // ...