From 5d2947a03020f1a1ac13c61242e2c39807543efe Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Wed, 7 Dec 2016 17:14:56 +0100 Subject: [PATCH] more text --- architecture/itasks.tex | 19 ++++--------------- architecture/mtasks.tex | 40 ++++++++++++++++++++++++++++++++++++--- architecture/preamble.tex | 1 + 3 files changed, 42 insertions(+), 18 deletions(-) diff --git a/architecture/itasks.tex b/architecture/itasks.tex index acc5da1..cbda838 100644 --- a/architecture/itasks.tex +++ b/architecture/itasks.tex @@ -18,21 +18,10 @@ the task that can later on be used to kill a task even when it is not finished. During initialization the task value is \CI{NoValue}. When the initialization is done and the task is loaded the value becomes an unstable \CI{Int} value that denotes the task identification. When the task is finished the value -becomes stable and no interaction can be done with the type from then on. - -\todo{Dit wat hieronder staat omschrijven} - -To make the integration of \mTask{}s in \iTasks{} more orthogonal we need a -special kind of task that serves as a mothertask that has the type visible in -Listing~\ref{lst:mothertask}. At first the system must be initialized with the -first given function. This will setup the necessary communication tasks and -SDSs used for interal storage and communication. This task is automatically -started when the system boots up. To add a task one has to call \CI{addmTask} -which will send the task to the system and evaluate it. Currently the only way -of getting info back is through SDSs that are used in the \mTask. Some tasks -are designed to run indefinite, for example temperature monitoring, and to -remove them the \CI{delmTask} function is introduced that will remove the task -and return a success value. +becomes stable and no interaction can be done with the type from then on. Tasks +can be deleted at runtime by using the \CI{delmTask} function that will return +a task of type \CI{Bool} to indicate success. All type signatures are available +in Listing~\ref{lst:mothertask}. \begin{lstlisting}[language=Clean,label={lst:mothertask}] mTask :: DeviceSpec -> Task () diff --git a/architecture/mtasks.tex b/architecture/mtasks.tex index f7197f2..be43d3c 100644 --- a/architecture/mtasks.tex +++ b/architecture/mtasks.tex @@ -1,13 +1,47 @@ -\emph{mTask}s are written in a shallowly embedded class-based DSL that due to +\subsection{mTask} +\mTask{}s are written in a shallowly embedded class-based DSL that due to the nature of it can be easily extended in language and in view. Currently there is a view for generating \emph{C}-code and a view for simulating -\emph{mTasks} using \iTasks{}. Currently the \emph{mTask} code includes +\mTask{}s using \iTasks{}. Currently the \mTask{} code includes functionality for running a small task server on the embedded device. These features will not be used in this project as the microcontroller will serve a slightly different purpose, namely serve as a task executioner instead of a server. The bytecode compilation also adds a class that represents all things compilable in bytecode to make sure all the basic types can be compiled. Both -signatures are shown in Listing~\ref{lst:bytecode}. +signatures are shown in Listing~\ref{lst:bytecode}. We only use a subset of the +original \mTask{} definitions because we do not use the functionality for +managing tasks. + +\subsection{Classes} +To make the DSL easily extendable with functionality without losing +extendability of views it as a set of classes that can be implemented by any +data type. + +Arithmetic operations and boolean operators are defined respectively in the +\CI{arith} and \CI{boolExpr} class. Note that the functions defined by the +class have some restrictions for specific views. This is basically the +translation from Clean basic type to the representation in the data type. + +\begin{lstlisting}[language=Clean,label={lst:arith}] +class arith v where + lit :: t -> v t Expr | toCode t & toByteCode t + (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | type, +, zero t & isExpr p & isExpr q + (-.) infixl 6 :: (v t p) (v t q) -> v t Expr | type, -, zero t & isExpr p & isExpr q + (*.) infixl 7 :: (v t p) (v t q) -> v t Expr | type, *, zero, one t & isExpr p & isExpr q + (/.) infixl 7 :: (v t p) (v t q) -> v t Expr | type, / t & isExpr p & isExpr q + +class boolExpr v where + (&.) infixr 3 :: (v Bool p) (v Bool q) -> v Bool Expr | isExpr p & isExpr q + (|.) infixr 2 :: (v Bool p) (v Bool q) -> v Bool Expr | isExpr p & isExpr q + Not :: (v Bool p) -> v Bool Expr | isExpr p + (==.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & isExpr p & isExpr q + (!=.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & isExpr p & isExpr q + (<.) infix 4 :: (v a p) (v a q) -> v Bool Expr | <, Ord, toCode a & isExpr p & isExpr q + (>.) infix 4 :: (v a p) (v a q) -> v Bool Expr | <, Ord, toCode a & isExpr p & isExpr q + (<=.) infix 4 :: (v a p) (v a q) -> v Bool Expr | <, Ord, toCode a & isExpr p & isExpr q + (>=.) infix 4 :: (v a p) (v a q) -> v Bool Expr | <, Ord, toCode a & isExpr p & isExpr q +\end{lstlisting} + In the future a state will probably need to be added to the \CI{Bytecode} type to keep track of some information during bytecode compilation. diff --git a/architecture/preamble.tex b/architecture/preamble.tex index cdabd02..04e7185 100644 --- a/architecture/preamble.tex +++ b/architecture/preamble.tex @@ -2,6 +2,7 @@ \usepackage[british]{babel} \usepackage{geometry} +\usepackage[hidelinks]{hyperref} \usepackage{rutitlepage} \usepackage{booktabs} \usepackage{clean} -- 2.20.1