-The \gls{MTASK} system is a \gls{TOP} programming environment for programming microprocessors.
-It is implemented as an\gls{EDSL} in \gls{CLEAN} using class-based---or tagless-final---embedding (See \cref{ssec:tagless}).
-Due to the nature of the embedding technique, it is possible to have multiple interpretations of---or views on---programs written in the \gls{MTASK} language.
-The following interpretations are available for \gls{MTASK}.
-
-\begin{itemize}
- \item Pretty printer
-
- This interpretation converts the expression to a string representation.
- \item Simulator
-
- The simulator converts the expression to a ready-for-work \gls{ITASK} simulation in which the user can inspect and control the simulated peripherals and see the internal state of the tasks.
- \item Compiler
-
- The compiler compiles the \gls{MTASK} program at runtime to a specialised bytecode.
- Using a handful of integration functions and tasks, \gls{MTASK} tasks can be executed on microprocessors and integrated in \gls{ITASK} as if they were regular \gls{ITASK} tasks.
- Furthermore, with special language constructs, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs.
-\end{itemize}
-
-When using the compiler interpretation in conjunction with the \gls{ITASK} integration, \gls{MTASK} is a heterogeneous \gls{DSL}.
-I.e.\ some components---e.g.\ the \gls{RTS} on the microprocessor---is largely unaware of the other components in the system.
-Furthermore, it is executed on a completely different architecture.
-The \gls{MTASK} language consists of a host language---a simply-typed $\lambda$-calculua with support for some basic types, function definition and data types (see \cref{sec:expressions})---enriched with a task language (see \cref{sec:top}).
-
-\section{Types}
-To leverage the type checker of the host language, types in the \gls{MTASK} language are expressed as types in the host language, to make the language type safe.
-However, not all types in the host language are suitable for microprocessors that may only have \qty{2}{\kibi\byte} of \gls{RAM} so class constraints are therefore added to the \gls{DSL} functions.
-The most used class constraint is the \cleaninline{type} class collection containing functions for serialization, printing, \gls{ITASK} constraints \etc.
-Many of these functions can be derived using generic programming.
-An even stronger restriction on types is defined for types that have a stack representation.
-This \cleaninline{basicType} class has instances for many \gls{CLEAN} basic types such as \cleaninline{Int}, \cleaninline{Real} and \cleaninline{Bool}.
-The class constraints for values in \gls{MTASK} are omnipresent in all functions and therefore often omitted throughout throughout the chapters for brevity and clarity.
-
-\begin{table}[ht]
- \centering
- \begin{tabular}{lll}
- \toprule
- \gls{CLEAN}/\gls{MTASK} & \gls{CPP} type & \textnumero{}bits\\
- \midrule
- \cleaninline{Bool} & \cinline{bool} & 16\\
- \cleaninline{Char} & \cinline{char} & 16\\
- \cleaninline{Int} & \cinline{int16_t} & 16\\
- \cleaninline{:: Long} & \cinline{int32_t} & 32\\
- \cleaninline{Real} & \cinline{float} & 32\\
- \cleaninline{:: T = A \| B \| C} & \cinline{enum} & 16\\
- \bottomrule
- \end{tabular}
- \caption{Mapping from \gls{CLEAN}/\gls{MTASK} data types to \gls{CPP} datatypes.}%
- \label{tbl:mtask-c-datatypes}
-\end{table}
-
-The \gls{MTASK} language consists of a core collection of type classes bundled in the type class \cleaninline{class mtask}.
-Every interpretation implements the type classes in the \cleaninline{mtask} class
-There are also \gls{MTASK} extensions that not every interpretation implements such as peripherals and integration with \gls{ITASK}.
-
-\Cref{lst:constraints} contains the definitions for the type constraints and shows some example type signatures for typical \gls{MTASK} expressions and tasks.
-\todo{uitleggen}
-
-\begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}]
-:: Main a = { main :: a }
-:: In a b = (In) infix 0 a b
-
-class type t | iTask, ... ,fromByteCode, toByteCode t
-class basicType t | type t where ...
-
-class mtask v | expr, ..., int, real, long v
-
-someExpr :: v Int | mtask v
-someExpr = ...
-
-someTask :: MTask v Int | mtask v
-someTask =
- sensor1 config1 \sns1->
- sensor2 config2 \sns2->
- fun \fun1= ( ... )
- In fun \fun2= ( ... )
- In {main=mainexpr}
-\end{lstClean}
-
-\section{Expressions}\label{sec:expressions}
-\Cref{lst:expressions} shows the \cleaninline{expr} class containing the functionality to lift values from the host language to the \gls{MTASK} language (\cleaninline{lit}); perform number and boolean arithmetics; do comparisons; and conditional execution.
-For every common arithmetic operator in the host language, an \gls{MTASK} variant is present, suffixed by a period to not clash with \gls{CLEAN}'s builtin operators.
-
-\begin{lstClean}[caption={The \gls{MTASK} class for expressions},label={lst:expressions}]
-class expr v where
- lit :: t -> v t | type t
- (+.) infixl 6 :: (v t) (v t) -> v t | basicType, +, zero t
- ...
- (&.) infixr 3 :: (v Bool) (v Bool) -> v Bool
- (|.) infixr 2 :: (v Bool) (v Bool) -> v Bool
- Not :: (v Bool) -> v Bool
- (==.) infix 4 :: (v a) (v a) -> v Bool | Eq, basicType a
- ...
- If :: (v Bool) (v t) (v t) -> v t | type t
-\end{lstClean}
-
-Conversion to-and-fro data types is available through the overloaded functions \cleaninline{int}, \cleaninline{long} and \cleaninline{real}.
-
-\begin{lstClean}[caption={Type conversion functions in \gls{MTASK}.}]
-class int v a :: (v a) -> v Int
-class real v a :: (v a) -> v Real
-class long v a :: (v a) -> v Long
-\end{lstClean}
-
-Finally, values from the host language must be explicitly lifted to the \gls{MTASK} language using the \cleaninline{lit} function.
-For convenience, there are many lower-cased macro definitions for often used constants such as \cleaninline{true :== lit True}, \cleaninline{false :== lit False}, \etc.
-
-\Cref{lst:example_exprs} shows some examples of these expressions.
-\cleaninline{e0} defines the literal $42$, \cleaninline{e1} calculates the literal $42.0$ using real numbers.
-\cleaninline{e2} compares \cleaninline{e0} and \cleaninline{e1} as integers and if they are equal it returns the \cleaninline{e2}$/2$ and \cleaninline{e0} otherwise.
-\cleaninline{approxEqual} performs an approximate equality---albeit not taking into account all floating point pecularities---and demonstrates that \gls{CLEAN} can be used as a macro language, i.e.\ maximise linguistic reuse~\cite{krishnamurthi_linguistic_2001}.
-\todo{uitzoeken waar dit handig is}
-When calling \cleaninline{approxEqual} in an \gls{MTASK} function, the resulting code is inlined.
-
-\begin{lstClean}[label={lst:example_exprs},caption={Example \gls{MTASK} expressions.}]
-e0 :: v Int | expr v
-e0 = lit 42
-
-e1 :: v Real | expr v
-e1 = lit 38.0 + real (lit 4)
-
-e2 :: v Int | expr v
-e2 = if' (e0 ==. int e1)
- (int e1 /. lit 2) e0
-
-approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v
-approxEqual x y eps = if' (x == y) true
- ( if' (x > y)
- (y -. x < eps)
- (x -. y < eps)
- )
-\end{lstClean}
-
-\subsection{Data Types}
-Most of \gls{CLEAN}'s basic types have been mapped on \gls{MTASK} types.
-However, it can be useful to have access to compound types as well.
-All types in \gls{MTASK} must have a fixed size representation on the stack so sum types are not (yet) supported.
-While it is possible to lift types using the \cleaninline{lit} function, you cannot do anything with the types besides passing them around but they are being produced by some parallel task combinators (see \cref{sssec:combinators_parallel}).
-To be able to use types as first class citizens, constructors and field selectors are required.
-\Cref{lst:tuple_exprs} shows the scaffolding for supporting tuples in \gls{MTASK}.
-Besides the constructors and field selectors, there is also a helper function available that transforms a function from a tuple of \gls{MTASK} expressions to an \gls{MTASK} expression of a tuple.
-
-\begin{lstClean}[label={lst:tuple_exprs},caption={Tuple constructor and field selectors in \gls{MTASK}.}]
-class tupl v where
- tupl :: (v a) (v b) -> v (a, b) | type a & type b
- first :: (v (a, b)) -> v a | type a & type b
- second :: (v (a, b)) -> v b | type a & type b
-
- tupopen f :== \v->f (first v, second v)
-\end{lstClean}
-
-\subsection{Functions}
-Adding functions to the language is achieved by one multi-parameter class to the \gls{DSL}.
-By using \gls{HOAS}, both the function definition and the calls to the function can be controlled by the \gls{DSL}~\citep{pfenning_higher-order_1988,chlipala_parametric_2008}.
-As \gls{MTASK} only supports first-order functions and does not allow partial function application.
-Using a type class of this form, this restriction can be enforced on the type level.
-Instead of providing one instance for all functions, a single instance per function arity is defined.
-Also, \gls{MTASK} only supports top-level functions which is enforced by the \cleaninline{Main} box.
-The definition of the type class and the instances for an example interpretation are as follows:
-\todo{uitbreiden}
-
-\begin{lstClean}[caption={Functions in \gls{MTASK}.}]
-class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
- -> Main (MTask v u)
-
-instance fun () Inter where ...
-instance fun (Inter a) Inter | type a where ...
-instance fun (Inter a, Inter b) Inter | type a where ...
-instance fun (Inter a, Inter b, Inter c) Inter | type a where ...
-...
-\end{lstClean}
-
-Deriving how to define and use functions from the type is quite the challenge even though the resulting syntax is made easier using the infix type \cleaninline{In}.
-\Cref{lst:function_examples} show the factorial function, a tail-call optimised factorial function and a function with zero arguments to demonstrate the syntax.
-Splitting out the function definition for each single arity means that that for every function arity and combination of arguments, a separate class constraint must be created.
-Many of the often used functions are already bundled in the \cleaninline{mtask} class constraint collection.
-\cleaninline{factorialtail} shows a manually added class constraint.
-Definiting zero arity functions is shown in the \cleaninline{zeroarity} expression.
-Finally, \cleaninline{swapTuple} shows an example of a tuple being swapped.
-
-% VimTeX: SynIgnore on
-\begin{lstClean}[label={lst:function_examples},caption={Function examples in \gls{MTASK}.}]
-factorial :: Main (v Int) | mtask v
-factorial =
- fun \fac=(\i->if' (i <. lit 1)
- (lit 1)
- (i *. fac (i -. lit 1)))
- In {main = fac (lit 5) }
-
-factorialtail :: Main (v Int) | mtask v & fun (v Int, v Int) v
-factorialtail =
- fun \facacc=(\(acc, i)->if' (i <. lit 1)
- acc
- (fac (acc *. i, i -. lit 1)))
- In fun \fac=(\i->facacc (lit 1, i))
- In {main = fac (lit 5) }
-
-zeroarity :: Main (v Int) | mtask v
-zeroarity =
- fun \fourtytwo=(\()->lit 42)
- In fun \add=(\(x, y)->x +. y)
- In {main = add (fourtytwo (), lit 9)}
-
-swapTuple :: Main (v (Int, Bool)) | mtask v
-swapTuple =
- fun \swap=(tupopen \(x, y)->tupl y x)
- In {main = swap (tupl true (lit 42)) }
-\end{lstClean}
-% VimTeX: SynIgnore off
-
-\section{Tasks}\label{sec:top}
-\Gls{MTASK}'s task language can be divided into three categories, namely
-\begin{enumerate*}
- \item Basic tasks, in most \gls{TOP} systems, the basic tasks are called editors, modelling the interactivity with the user.
- In \gls{MTASK}, there are no \emph{editors} in that sense but there is interaction with the outside world through microprocessor peripherals such as sensors and actuators.
- \item Task combinators provide a way of describing the workflow.
- They combine one or more tasks into a compound task.
- \item \glspl{SDS} in \gls{MTASK} can be seen as references to data that can be shared using many-to-many communication and are only accessible from within the task language to ensure atomicity.
-\end{enumerate*}
-
-As \gls{MTASK} is integrated with \gls{ITASK}, the same stability distinction is made for task values.
-A task in \gls{MTASK} is denoted by the \gls{DSL} type synonym shown in \cref{lst:task_type}.
-
-\begin{lstClean}[label={lst:task_type},caption={Task type in \gls{MTASK}.}]
-:: MTask v a :== v (TaskValue a)
-:: TaskValue a
- = NoValue
- | Value a Bool
-\end{lstClean}
-
-\subsection{Basic tasks}
-The most rudimentary basic tasks are the \cleaninline{rtrn} and \cleaninline{unstable} tasks.
-They lift the value from the \gls{MTASK} expression language to the task domain either as a stable value or an unstable value.
-There is also a special type of basic task for delaying execution.
-The \cleaninline{delay} task---given a number of milliseconds---yields an unstable value while the time has not passed.
-Once the specified time has passed, the time it overshot the planned time is yielded as a stable task value.
-
-\begin{lstClean}[label={lst:basic_tasks},caption={Function examples in \gls{MTASK}.}]
-class rtrn v :: (v t) -> MTask v t
-class unstable v :: (v t) -> MTask v t
-class delay v :: (v n) -> MTask v n | long v n
-\end{lstClean}
-
-\subsubsection{Peripherals}\label{sssec:peripherals}
-For every sensor or actuator, basic tasks are available that allow interaction with the specific peripheral.
-The type classes for these tasks are not included in the \cleaninline{mtask} class collection as not all devices nor all language interpretations have such peripherals connected.
-\todo{Historically, peripheral support has been added \emph{by need}.}
-
-\Cref{lst:dht} and \cref{lst:gpio} show the type classes for \glspl{DHT} sensors and \gls{GPIO} access.
-Other peripherals have similar interfaces, they are available in the \cref{sec:aux_peripherals}.
-For the \gls{DHT} sensor there are two basic tasks, \cleaninline{temperature} and \cleaninline{humidity}, that---will given a \cleaninline{DHT} object---produce a task that yields the observed temperature in \unit{\celcius} or relative humidity as a percentage as an unstable value.
-Currently, two different types of \gls{DHT} sensors are supported, the \emph{DHT} family of sensors connect through $1$-wire protocol and the \emph{SHT} family of sensors connected using \gls{I2C} protocol.
-Creating such a \cleaninline{DHT} object is very similar to creating functions in \gls{MTASK} and uses \gls{HOAS} to make it type safe.
-
-\begin{lstClean}[label={lst:dht},caption{The \gls{MTASK} interface for \glspl{DHT} sensors.}]
-:: DHT //abstract
-:: DHTInfo
- = DHT_DHT Pin DHTtype
- | DHT_SHT I2CAddr
-:: DHTtype = DHT11 | DHT21 | DHT22
-class dht v where
- DHT :: DHTInfo ((v DHT) -> Main (v b)) -> Main (v b) | type b
- temperature :: (v DHT) -> MTask v Real
- humidity :: (v DHT) -> MTask v Real
-
-measureTemp :: Main (MTask v Real) | mtask v & dht v
-measureTemp = DHT (DHT_SHT (i2c 0x36)) \dht->
- {main=temperature dht}
-\end{lstClean}
-
-\Gls{GPIO} access is divided into three classes: analog, digital and pin modes.
-For all pins and pin modes an \gls{ADT} is available that enumerates the pins.
-The analog \gls{GPIO} pins of a microprocessor are connected to an \gls{ADC} that translates the voltage to an integer.
-Analog \gls{GPIO} pins can be either read or written to.
-Digital \gls{GPIO} pins only report a high or a low value.
-The type class definition is a bit more complex since analog \gls{GPIO} pins can be used as digital \gls{GPIO} pins as well.
-Therefore, if the \cleaninline{p} type implements the \cleaninline{pin} class---i.e.\ either \cleaninline{APin} or \cleaninline{DPin}---the \cleaninline{dio} class can be used.
-\Gls{GPIO} pins usually operate according to a certain pin mode that states whether the pin acts as an input pin, an input with an internal pull-up resistor or an output pin.
-This setting can be applied using the \cleaninline{pinMode} class by hand or by using the \cleaninline{declarePin} \gls{GPIO} pin constructor.
-Setting the pin mode is a task that immediately finisheds and fields a stable unit value.
-Writing to a pin is also a task that immediately finishes but yields the written value instead.
-Reading a pin is a task that yields an unstable value---i.e.\ the value read from the actual pin.
-
-\begin{lstClean}[label={lst:gpio},caption{The \gls{MTASK} interface for \gls{GPIO} access.}]
-:: APin = A0 | A1 | A2 | A3 | A4 | A5
-:: DPin = D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13
-:: PinMode = PMInput | PMOutput | PMInputPullup
-:: Pin = AnalogPin APin | DigitalPin DPin
-class pin p :: p -> Pin
-
-class aio v where
- writeA :: (v APin) (v Int) -> MTask v Int
- readA :: (v APin) -> MTask v Int
-
-class dio p v | pin p where
- writeD :: (v p) (v Bool) -> MTask v Bool
- readD :: (v p) -> MTask v Bool | pin p
-
-class pinMode v where
- pinMode :: (v PinMode) (v p) -> MTask v () | pin p
- declarePin :: p PinMode ((v p) -> Main (v a)) -> Main (v a) | pin p
-\end{lstClean}
-
-\subsection{Task combinators}
-Task combinators are used to combine multiple tasks into one to describe workflows.
-There are three main types of task combinators, namely:
-\begin{enumerate*}
- \item Sequential combinators that execute tasks one after the other, possibly using the result of the left hand side.
- \item Parallel combinators that execute tasks at the same time combining the result.
- \item Miscellaneous combinators that change the semantics of a task---e.g.\ repeat it or delay execution.
-\end{enumerate*}
-
-\subsubsection{Sequential}
-Sequential task combination allows the right-hand side task to observe the left-hand side task value.
-All seqential task combinators are expressed in the \cleaninline{expr} class and can be---and are by default---derived from the Swiss army knife step combinator \cleaninline{>>*.}.
-This combinator has a single task on the left-hand side and a list of \emph{task continuations} on the right-hand side.
-The list of task continuations is checked every rewrite step and if one of the predicates matches, the task continues with the result of this combination.
-\cleaninline{>>=.} is a shorthand for the bind operation, if the left-hand side is stable, the right-hand side function is called to produce a new task.
-\cleaninline{>>|.} is a shorthand for the sequence operation, if the left-hand side is stable, it continues with the right-hand side task.
-The \cleaninline{>>~.} and \cleaninline{>>..} combinators are variants of the ones above that ignore the stability and continue on an unstable value as well.
-
-\begin{lstClean}[label={lst:mtask_sequential},caption={Sequential task combinators in \gls{MTASK}.}]
-class step v | expr v where
- (>>*.) infixl 1 :: (MTask v t) [Step v t u] -> MTask v u
- (>>=.) infixl 0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u
- (>>|.) infixl 0 :: (MTask v t) (MTask v u) -> MTask v u
- (>>~.) infixl 0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u
- (>>..) infixl 0 :: (MTask v t) (MTask v u) -> MTask v u
-
-:: Step v t u
- = IfValue ((v t) -> v Bool) ((v t) -> MTask v u)
- | IfStable ((v t) -> v Bool) ((v t) -> MTask v u)
- | IfUnstable ((v t) -> v Bool) ((v t) -> MTask v u)
- | Always (MTask v u)
-\end{lstClean}
-
-\todo{more examples step?}
-
-The following listing shows an example of a step in action.
-The \cleaninline{readPinBin} function produces an \gls{MTASK} task that classifies the value of an analogue pin into four bins.
-It also shows that the nature of embedding allows the host language to be used as a macro language.
-Furthermore
-
-\begin{lstClean}[label={lst:mtask_readpinbin},caption={Read an analog pin and bin the value in \gls{MTASK}.}]
-readPinBin :: Int -> Main (MTask v Int) | mtask v
-readPinBin lim = declarePin PMInput A2 \a2->
- { main = readA a2 >>*.
- [ IfValue (\x->x <. lim) (\_->rtrn (lit bin))
- \\ lim <-[64,128,192,256]
- & bin <- [0..]]}
-\end{lstClean}
-
-\subsubsection{Parallel}\label{sssec:combinators_parallel}
-The result of a parallel task combination is a compound that actually executes the tasks at the same time.
-
-There are two types of parallel task combinators (see \cref{lst:mtask_parallel}).
-The conjunction combinator (\cleaninline{.&&.}) combines the result by putting the values from both sides in a tuple.
-The stability of the task depends on the stability of both children.
-If both children are stable, the result is stable, otherwise the result is unstable.
-The disjunction combinator (\cleaninline{.\|\|.}) combines the results by picking the leftmost, most stable task.
-The semantics are easily described using \gls{CLEAN} functions shown in \cref{lst:semantics_con,lst:semantics_dis}.
-
-\begin{figure}[ht]
- \centering
- \begin{subfigure}[t]{.5\textwidth}
- \begin{lstClean}[caption={Semantics of the\\conjunction combinator.},label={lst:semantics_con}]
-con :: (TaskValue a) (TaskValue b)
- -> TaskValue (a, b)
-con NoValue r = NoValue
-con l NoValue = NoValue
-con (Value l ls) (Value r rs)
- = Value (l, r) (ls && rs)
-
- \end{lstClean}
- \end{subfigure}%
- \begin{subfigure}[t]{.5\textwidth}
- \begin{lstClean}[caption={Semantics of the\\disjunction combinator.},label={lst:semantics_dis}]
-dis :: (TaskValue a) (TaskValue a)
- -> TaskValue a
-dis NoValue r = r
-dis l NoValue = l
-dis (Value l ls) (Value r rs)
- | rs = Value r True
- | otherwise = Value l ls
- \end{lstClean}
- \end{subfigure}
-\end{figure}
-
-\begin{lstClean}[label={lst:mtask_parallel},caption={Parallel task combinators in \gls{MTASK}.}]
-class (.&&.) infixr 4 v :: (MTask v a) (MTask v b) -> MTask v (a, b)
-class (.||.) infixr 3 v :: (MTask v a) (MTask v a) -> MTask v a
-\end{lstClean}
-
-\Cref{lst:mtask_parallel_example} gives an example of the parallel task combinator.
-This program will read two pins at the same time, returning when one of the pins becomes \arduinoinline{HIGH}.
-If the combinator was the \cleaninline{.&&.} instead, the type would be \cleaninline{MTask v (Bool, Bool)} and the task would only return when both pins have been \arduinoinline{HIGH} but not necessarily at the same time.
-
-\begin{lstClean}[label={lst:mtask_parallel_example},caption={Parallel task combinator example in \gls{MTASK}.}]
-task :: MTask v Bool
-task =
- declarePin D0 PMInput \d0->
- declarePin D1 PMInput \d1->
- let monitor pin = readD pin >>*. [IfValue (\x->x) \x->rtrn x]
- In {main = monitor d0 .||. monitor d1}
-\end{lstClean}
-
-\subsubsection{Repeat}
-The \cleaninline{rpeat} combinator executes the child task.
-If a stable value is observed, the task is reinstated.
-The functionality of \cleaninline{rpeat} can also be simulated by using functions and sequential task combinators and even made to be stateful as can be seen in \cref{lst:blinkthreadmtask}.
-
-\begin{lstClean}[label={lst:mtask_repeat},caption={Repeat task combinators in \gls{MTASK}.}]
-class rpeat v where
- rpeat :: (MTask v a) -> MTask v a
-\end{lstClean}
-
-To demonstrate the combinator, \cref{lst:mtask_repeat_example} show \cleaninline{rpeat} in use.
-This task will mirror the value read from analog \gls{GPIO} pin \cleaninline{A1} to pin \cleaninline{A2} by constantly reading the pin and writing the result.
-
-\begin{lstClean}[label={lst:mtask_repeat_example},caption={Exemplatory repeat task in \gls{MTASK}.}]
-task :: MTask v Int | mtask v
-task =
- declarePin A1 PMInput \a1->
- declarePin A2 PMOutput \a2->
- {main = rpeat (readA a1 >>~. writeA a2)}
-\end{lstClean}
-
-\subsection{\texorpdfstring{\Acrlongpl{SDS}}{Shared data sources}}
-\Glspl{SDS} in \gls{MTASK} are by default references to shared memory.
-Similar to peripherals (see \cref{sssec:peripherals}), they are constructed at the top level and are accessed through interaction tasks.
-The \cleaninline{getSds} task yields the current value of the \gls{SDS} as an unstable value.
-This behaviour is similar to the \cleaninline{watch} task in \gls{ITASK}.
-Writing a new value to an \gls{SDS} is done using \cleaninline{setSds}.
-This task yields the written value as a stable result after it is done writing.
-Getting and immediately after setting an \gls{SDS} is not an \emph{atomic} operation.
-It is possible that another task accesses the \gls{SDS} in between.
-To circumvent this issue, \cleaninline{updSds} is created, this task atomically updates the value of the \gls{SDS}.
-
-\begin{lstClean}[label={lst:mtask_sds},caption={\Glspl{SDS} in \gls{MTASK}.}]
-:: Sds a // abstract
-class sds v where
- sds :: ((v (Sds t)) -> In t (Main (MTask v u))) -> Main (MTask v u)
- getSds :: (v (Sds t)) -> MTask v t
- setSds :: (v (Sds t)) (v t) -> MTask v t
- updSds :: (v (Sds t)) ((v t) -> v t) -> MTask v t
-\end{lstClean}
-
-\todo{examples sdss}
-
-\chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
-\label{chp:green_computing_mtask}
-
-\chapter{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}%
-\label{chp:integration_with_itask}