-\section{mTask}
The \gls{mTask}-\gls{EDSL} is the basis on which the system is built. The
\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ to support several views
such as an \gls{iTasks} simulation and a \gls{C}-code generator. The \gls{EDSL}
The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and
therefore it is very suitable to have a new backend that partly implements the
-given classes. The following subsections show the details of the \gls{EDSL}
+given classes. The following sections show the details of the \gls{EDSL}
that are used in this extension. The parts of the \gls{EDSL} that are not used
will not be discussed and the details of those parts can be found in the cited
literature.
instance isExpr Expr
\end{lstlisting}
-\subsection{Semantics}
-\gls{mTask} do not behave like functions but more like
-\gls{iTasks}-\glspl{Task}. When an \gls{mTask} is created it returns immediatly
-and the \gls{Task} will be executed sometime in the future. \glspl{Task} can
-run at an interval and they can start other tasks.
-\todo{Meer uitwijden over de mTask semantiek}
-
-\subsection{Expressions}
+\section{Semantics}
+The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated
+alongside the code for the \glspl{Task}. This engine will execute the
+\glspl{mTask} according to certain rules and semantics.
+\glspl{mTask} do not behave like functions but more like
+\gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either his timer runs
+out or when it is started by another \gls{mTask}. When an \gls{mTask} is
+queued it does not block the execution but it will return immediately while
+the actual \gls{Task} will be executed some time in the future.
+
+The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
+semantics. This engine expressed in pseudocode is listed as
+Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
+time. When the waiting time has not passed the delta is subtracted and they are
+pushed to the end of the queue. When the waiting has has surpassed they are
+executed. When a \gls{mTask} wants to queue another \gls{mTask} it can just
+append it to the queue.
+
+\begin{algorithm}[H]
+ \KwData{\textbf{queue} queue$[]$, \textbf{time} $t, t_p$}
+
+ $t\leftarrow\text{now}()$\;
+ \Begin{
+ \While{true}{
+ $t_p\leftarrow t$\;
+ $t\leftarrow\text{now}()$\;
+ \If{notEmpty$($queue$)$}{
+ $task\leftarrow \text{queue.pop}()$\;
+ $task$.wait $-= t-t_p$\;
+ \eIf{$task.wait>t_0$}{
+ queue.append$(task)$\;
+ }{
+ run\_task$(task)$\;
+ }
+ }
+ }
+ }
+ \caption{Engine pseudocode for the \gls{C}- and
+ \gls{iTasks}-backends}\label{lst:engine}
+\end{algorithm}
+
+\section{Expressions}
Expressions in the \gls{mTask}-\gls{EDSL} are divided into two types, namely
boolean expressions and arithmetic expressions. The class of arithmetic
language constructs also contains the function \CI{lit} that lifts a
host-language value in to the \gls{EDSL} domain. All standard arithmetic
-functions are included but are omitted for brevity. Moreover the class
-restrictions are only shown in the first functions and are later omitted. Both
-the boolean expression and arithmetic expression classes are shown in
-Listing~\ref{lst:arithbool}.
+functions are included in the \gls{EDSL} but are omitted in the example for
+brevity. Moreover, the class restrictions are only shown in the first functions
+and omitted in subsequent funcitons. Both the boolean expression and arithmetic
+expression classes are shown in Listing~\ref{lst:arithbool}.
\begin{lstlisting}[language=Clean,label={lst:arithbool},
caption={Basic classes for expressions}]
(==.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & ...
\end{lstlisting}
-\subsection{Control flow}
+\section{Control flow}
Looping of \glspl{Task} happens because \glspl{Task} are launched at regular
intervals or relaunch themselves. Therefore there is no need for loop control
-flow functionality such as \CI{While} or \CI{For} constructions. The main
-control flow is the sequence operator and the \CI{If} statement. Both are shown
-in Listing~\ref{lst:control}. The first class of \CI{If} statements describe
-the regular if statement. The expressions given can have any role. The
-functional dependency on \CI{s} determines the return type of the statement.
-The sequence operator is very straightforward and just ties the two expressions
-together in sequence.
+flow functionality such as \emph{while} or \emph{for} constructions. The main
+control flow is the sequence operator and the \emph{if} statement. Both are
+shown in Listing~\ref{lst:control}. The first class of \emph{If} statements
+describe the regular \emph{if} statement. The expressions given can have any
+role. The functional dependency on \CI{s} determines the return type of the
+statement. The sequence operator is very straightforward and just ties the two
+expressions together in sequence.
\begin{lstlisting}[%
language=Clean,label={lst:control},caption={Control flow operators}]
(:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ...
\end{lstlisting}
-\subsection{Input/Output and class extensions}
+\section{Input/Output and class extensions}
All expressions that have an \CI{Upd} role can be assigned to. Examples of such
expressions are \glspl{SDS} and \gls{GPIO}. Moreover, class extensions can be
created for specific peripherals such as user LEDs. The classes facilitating
\end{lstlisting}
A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve
-as variables in the \gls{mTask} and will keep their value across executions.
+as variables in the \gls{mTask} and maintain their value across executions.
The classes associated with \glspl{SDS} are listed in
Listing~\ref{lst:sdsclass}. The \CI{Main} class is introduced to box an
\gls{mTask} and make it recognizable by the type system.
sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
\end{lstlisting}
-\subsection{Example \gls{mTask}}
+\section{Example mTask}
\todo{Also explain semantics about running tasks}
-Some example \glspl{mTask} using almost all of the functionality are show in
+Some example \glspl{mTask} using almost all of the functionality are shown in
Listing~\ref{lst:exmtask}. The \glspl{mTask} shown in the example do not belong
to a particular view and therefore are of the type \CI{View t r}. The
\CI{blink} \gls{mTask} show the classic \emph{Arduino} \emph{Hello World!}
-application that blinks a certain LED every interval. The \CI{thermostat}
+application that blinks a certain LED at each interval. The \CI{thermostat}
\gls{mTask} will enable a digital pin powering a cooling fan when the analog
pin representing a temperature sensor is too high. \CI{thermostat`} shows the
same program but now using the assignment style \gls{GPIO}.
repositories / msc-thesis1617.git / blobdiff