-Before execution some preparatory work is done. The stack will be initialized
-and the program counter and stack pointer are set to zero and the bottom
-respectively. Then, the interpreter executes one step at the time while the
-program counter is smaller than the program length. The code for this is listed
-in Listing~\ref{lst:interpr}. One execution step is basically a big switch
-statement going over all possible bytecode instructions. Some instructions are
-detailed upon in the listing. The \CI{BCPush} instruction is a little more
-complicated in real life because some decoding will take place as not all
-\CI{BCValue}'s are of the same length.
+ \Begin{
+ \While{true}{
+ \If{input\_available$()$}{
+ receive\_data()\;
+ }
+
+ $t\leftarrow \text{now}()$\;
+ \ForEach{$t\leftarrow tasks$}{
+ \uIf{is\_interrupt$(t)$ \textbf{and} had\_interrupt$(t)$}{
+ run\_task$(t)$\;
+ }
+ \ElseIf{$t-t.\text{lastrun} > t.\text{interval}$}{
+ run\_task$(t)$\;
+ \uIf{$t.\text{interval}==0$}{
+ delete\_task$(t)$\;
+ }\Else{
+ $t.\text{lastrun}\leftarrow t$\;
+ }
+ }
+ }
+ }
+ }
+ \caption{Engine pseudocode}\label{alg:client}
+\end{algorithm}
+
+\subsubsection{Storage}
+\glspl{Task} and \glspl{SDS} are stored on the client in one big memory space
+that is reserved at the start of the program. The space could also have been
+dynamically allocated but that would require using the heap which is unwanted
+in small memory environments. \Glspl{Task} grow from the bottom up and
+\glspl{SDS} grow from the top down. When a \gls{Task} or \gls{SDS} is removed,
+all \glspl{Task} residing in higher areas of the memory are relocated in the
+memory space to not leave holes. Both \glspl{Task} and \glspl{SDS} are stored
+as structures that are linked in the memory space, helper functions are
+available to loop through them without having to fiddle in the memory space
+itself. The instances for \glspl{Task} and \glspl{SDS} are shown in
+Listing~\ref{lst:structs} accompanied by the helper functions for \glspl{Task}.
+\Glspl{Task} consists of the length, interval, last run time, id and the
+bytecode. \Glspl{SDS} consist only of an id, value and type. The pointer to the
+bytecode of the \gls{Task} always points to the location in the memory space.
+
+\begin{lstlisting}[language=C,label={lst:structs},%
+ caption={The data type storing the \glspl{Task}}]
+struct task {
+ uint16_t tasklength;
+ uint16_t interval;
+ unsigned long lastrun;
+ uint8_t taskid;
+ uint8_t *bc;
+};
+
+struct task *task_head(void);
+struct task *task_next(struct task *t);
+
+struct sds {
+ int id;
+ int value;
+ char type;
+};
+
+struct sds *sds_head(void);
+struct sds *sds_next(struct sds *s);
+\end{lstlisting}
+
+\subsubsection{Interpretation}
+The execution of a \gls{Task} is started by running the \CI{run\_task} function
+and always starts with setting the program counter and stack
+pointer to zero and the bottom respectively. When finished, the
+interpreter executes one step at the time while the program counter is smaller
+than the program length. This code is listed in Listing~\ref{lst:interpr}. One
+execution step is basically a big switch statement going over all possible
+bytecode instructions. Of some instructions, the implementations are shown in
+the listing. The \CI{BCPush} instruction is a little more complicated in the
+real code because some decoding will take place as not all \CI{BCValue}s are of
+the same length and are encoded.