X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.mtask.tex;h=3ef01f19d27a6c424b67786b1a64f8f1bccb07a5;hb=36149fe97302e46248ceecfd8ef39faaea19991b;hp=d6fcbb329f6a4bfd82cbb416f104c914209a53b6;hpb=76254fbf2941fa0b5a02ab3a98104cad56959218;p=msc-thesis1617.git diff --git a/methods.mtask.tex b/methods.mtask.tex index d6fcbb3..3ef01f1 100644 --- a/methods.mtask.tex +++ b/methods.mtask.tex @@ -1,29 +1,29 @@ -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} -was designed to generate a ready-to-compile \gls{TOP}-like system for -microcontrollers such as the \gls{Arduino}~\cite{koopman_type-safe_nodate}% +The \gls{mTask}-\gls{EDSL} is the language used in the system. The +\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ and supported several +views such as an \gls{iTasks} simulation and a \gls{C}-code generator. The +\gls{EDSL} was designed to generate a ready-to-compile \gls{TOP}-like program +for microcontrollers such as the \gls{Arduino}~\cite{koopman_type-safe_nodate}% \cite{plasmeijer_shallow_2016}. 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 classes given. 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 +is 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. A view for the \gls{mTask}-\gls{EDSL} is a type with kind \CI{*->*->*}% \footnote{A type with two free type variables.} that implements some of the classes given. The types do not have to be present as fields in the higher -kinded view and can, and will most often, be exclusively phantom types. A view -is of the form \CI{v t r}. The first type variable will be the type of the -view. The second type variable will be the type of the \gls{EDSL}-expression -and the third type variable represents the role of the expression. Currently -the role of the expressions form a hierarchy. The three roles and their -hierarchy are shown in Listing~\ref{lst:exprhier}. This implies that everything -is a statement, only a \CI{Upd} and a \CI{Expr} are expressions. The \CI{Upd} -restriction describes updatable expressions such as \gls{GPIO} pins and -\glspl{SDS}. +kinded view and can, and will most often, be exclusively phantom types. Thus, +views are of the form: \CI{:: v t r = ...}. The first type variable will be +the type of the view. The second type variable will be the type of the +\gls{EDSL}-expression and the third type variable represents the role of the +expression. Currently the role of the expressions form a hierarchy. The three +roles and their hierarchy are shown in Listing~\ref{lst:exprhier}. This implies +that everything is a statement, only a \CI{Upd} and a \CI{Expr} are +expressions. The \CI{Upd} restriction describes updatable expressions such as +\gls{GPIO} pins and \glspl{SDS}. \begin{lstlisting}[% label={lst:exprhier},caption={Expression role hierarchy}] @@ -43,8 +43,8 @@ language constructs also contains the function \CI{lit} that lifts a host-language value into the \gls{EDSL} domain. All standard arithmetic 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}. +and are omitted in subsequent functions. Both the boolean expression and +arithmetic expression classes are shown in Listing~\ref{lst:arithbool}. \begin{lstlisting}[label={lst:arithbool}, caption={Basic classes for expressions}] @@ -72,8 +72,9 @@ functional dependency on \CI{s} determines the return type of the statement. The listing includes examples of implementations that illustrate this dependency. -The sequence operator is very straightforward and its only function is to tie -the together in sequence. +The sequence operator is straightforward and its only function is to tie +two expressions together. The left expression is executed first, followed by +the right expression. \begin{lstlisting}[% label={lst:control},caption={Control flow operators}] @@ -93,7 +94,7 @@ class seq v where Values can be assigned to all expressions that have an \CI{Upd} role. Examples of such expressions are \glspl{SDS} and \gls{GPIO} pins. Moreover, class extensions can be created for specific peripherals such as built-in -\glspl{LED}. The classes facilitating this are shown in +\glspl{LED}. The classes facilitating this are shown in Listing~\ref{lst:sdsio}. In this way the assignment is the same for every assignable entity. @@ -122,10 +123,12 @@ class assign v where \end{lstlisting} A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve -as variables in the \gls{mTask} and maintain their value across executions. +as variables in \gls{mTask} and maintain their value across executions. +\glspl{SDS} can be used by multiple \glspl{Task} and can be used to share data. The classes associated with \glspl{SDS} are listed in Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an -\gls{mTask} and make it recognizable by the type system. +\gls{mTask} and make it recognizable by the type system by separating programs +and decorations such as \glspl{SDS}. \begin{lstlisting}[% label={lst:sdsclass},caption={\glspl{SDS} in \gls{mTask}}] @@ -151,9 +154,10 @@ 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 the \gls{Task} gets pushed to the end of the queue. When the waiting has surpassed -they are executed. When an \gls{mTask} wants to queue another \gls{mTask} it +they are executed. When an \gls{mTask} opts 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$} @@ -174,8 +178,9 @@ can just append it to the queue. } } \caption{Engine pseudocode for the \gls{C}- and - \gls{iTasks}-backend}\label{lst:engine} + \gls{iTasks}-view}\label{lst:engine} \end{algorithm} +~\\ To achieve this in the \gls{EDSL} a \gls{Task} class is added that work in a similar fashion as the \texttt{sds} class. This class is listed in @@ -201,7 +206,10 @@ to a particular view and therefore are of the type \CI{View t r}. The application that blinks a certain \gls{LED} every second. The \CI{thermostat} expression 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 -expression but now using the assignment style \gls{GPIO} technique. +expression but now using the assignment style \gls{GPIO} technique. The +\CI{thermostat} example also shows that it is not necessary to run everything +as a \CI{task}. The main program code can also just consist of the contents of +the root \CI{main} itself. \begin{lstlisting}[% label={lst:exmtask},caption={Some example \glspl{mTask}}]