available classes. Moreover, classes can be added at will without interfering
with the existing views.
-\section{Semantics}
+\section{\gls{Task} Semantics}
The current \gls{mTask} engine for devices does not support \glspl{Task} in the
sense that the \gls{C}-view does. \Glspl{Task} used with the \gls{C}-view are a
main program that executes code and launches \glspl{Task}. It was also possible
press of a button.
\end{itemize}
-\subsection{\glspl{SDS}}
+\section{\gls{SDS} semantics}
\Glspl{SDS} on a client are available on the server as well as regular
\gls{SDS}. However, the same freedom is not given on the \glspl{SDS} that
reside on the client. Not all types are suitable to be located on a client.
pub :: (v t Upd) -> v t Expr | type t
\end{lstlisting}
-\section{Bytecode compilation}\label{sec:compiler}
+\section{Bytecode compilation view}\label{sec:compiler}
The \glspl{mTask} are sent to the device in bytecode and are saved in the
memory of the device. To compile the \gls{EDSL} code to bytecode, a view is
added to the \gls{mTask}-system encapsulated in the type \CI{ByteCode}. As
instance serial ByteCode
\end{lstlisting}
-\section{Implementation}
\subsection{Instruction Set}
The instruction set is given in Listing~\ref{bc:instr}. The instruction set is
kept large, but under $255$, to get the highest expressively while keeping all
| BCReturn
\end{lstlisting}
-All single byte instructions can be converted automatically using the generic
+All single byte instructions are converted automatically using the generic
function \CI{consIndex} which returns the index of the constructor. The index
of the constructor is the byte value for all instructions. The last step of the
compilation is transforming the list of bytecode instructions to actual bytes.
makeStore [...] = [...]
\end{lstlisting}
-\section{Actual Compilation}
+\subsection{Actual Compilation}
All the previous functions are tied together with the \CI{toMessages} function.
This function compiles the bytecode and transforms the \gls{Task} in a message.
The \glspl{SDS} that were not already sent to the device are also added as
= ([MTSds sdsi e\\{sdsi,sdsval=e}<-newsdss] ++ [MTTask interval bc], newstate)
\end{lstlisting}
-\section{Example}
+\section{Examples}
The heating example given previously in Listing~\ref{lst:exmtask} would be
compiled to the following code. The left column indicates the
position in the program memory.
17-19: BCPush (Bool 0) //Else label
20 : BCDigitalWrite (Digital D0)
\end{lstlisting}
-
-\section{Interpreter}
-The client contains an interpreter to execute a \gls{Task}'s bytecode.
-
-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{lstlisting}[language=C,label={lst:interpr},%
- caption={Rough code outline for interpretation}]
-#define f16(p) program[pc]*265+program[pc+1]
-
-void run_task(struct task *t){
- uint8_t *program = t->bc;
- int plen = t->tasklength;
- int pc = 0;
- int sp = 0;
- while(pc < plen){
- switch(program[pc++]){
- case BCNOP:
- break;
- case BCPUSH:
- stack[sp++] = pc++ //Simplified
- break;
- case BCPOP:
- sp--;
- break;
- case BCSDSSTORE:
- sds_store(f16(pc), stack[--sp]);
- pc+=2;
- break;
- // ...
- case BCADD: trace("add");
- stack[sp-2] = stack[sp-2] + stack[sp-1];
- sp -= 1;
- break;
- // ...
- case BCJMPT: trace("jmpt to %d", program[pc]);
- pc = stack[--sp] ? program[pc]-1 : pc+1;
- break;
-}
-\end{lstlisting}
+\todo{More elaborate example}
+\todo{Add return instruction}