How an \gls{MTASK} task is compiled to this specification is shown in \cref{sec:compiler_imp}.
This package is then sent to the \gls{RTS} of the device for execution.
In order to execute a task, first the main expression is evaluated in the interpreter, resulting in a task tree.
-Using small-step reduction, this task tree is continuously rewritten by the rewrite engine of the \gls{RTS}.
+Then, using small-step reduction, the task tree is continuously rewritten by the rewrite engine of the \gls{RTS}.
At times, the reduction requires the evaluation of expressions, using the interpreter.
During every rewrite step, a task value is produced.
On the device, the \gls{RTS} may have multiple tasks at the same time active.
\end{figure}
\section{Compiler}\label{sec:compiler_imp}
+\todo[inline]{Zou je hier niet een prargraafje schrijven over dat dit een beetje speciale compiler is. Alle type checks worden al door Clean gedaan. Dat is voordat deze compiler ooit uitgevoerd gaat worden. Bovendien kan het Clean programma de te compileren byte code dynamisch maken. Dat staat natuurlijk al eerder een keer, maar je make niet aannemen dat iedereen alles leest (en nu nog weet)}
+\todo[inline]{Dit gaat wel hard de diepte in. Zou je niet een kort stukje schrijven over hoe je bytecode machine er uit ziet?
+ Heap: voor de huidige task tree die herschreven wordt.
+ Function code: sequence of bytecode instructie.
+ SDSs + Objects
+ Stack om expressies te evelaueren en function calls te doen.
+ Plaatje a la Figure 7.5.
+
+ Om de code te maken heb je een intsantie van alle classen in mTask nodig voor BCInterpret a.
+
+Voor veel lezers zou het genoeg zijn om alleen dat te snappen, maak het ze eenvoudig.}
\subsection{Compiler infrastructure}
The byte code compiler interpretation for the \gls{MTASK} language is implemented as a monad stack containing a writer monad and a state monad.
The writer monad is used to generate code snippets locally without having to store them in the monadic values.
Some optimisation is possible here but has currently not been implemented.
\begin{align*}
- \cschemeE{t_1\text{\cleaninline{>>*.}}t_2}{r} & =
+ \cschemeE{t_1\text{\cleaninline{>>*.}}e_2}{r} & =
\cschemeE{a_{f^i}}{r}, \langle f, i\rangle\in r;
\text{\cleaninline{BCMkTask}}~\text{\cleaninline{BCStable}}_{\stacksize{r}}; \cschemeE{t_1}{r};\\
- {} & \mathbin{\phantom{=}} \text{\cleaninline{BCMkTask}}~\text{\cleaninline{BCAnd}}; \text{\cleaninline{BCMkTask}}~(\text{\cleaninline{BCStep}}~(\cschemeS{t_2}{(r + [\langle l_s, i\rangle])}{\stacksize{t_1}}));\\
+ {} & \mathbin{\phantom{=}} \text{\cleaninline{BCMkTask}}~\text{\cleaninline{BCAnd}}; \text{\cleaninline{BCMkTask}}~(\text{\cleaninline{BCStep}}~(\cschemeS{e_2}{(r + [\langle l_s, i\rangle])}{\stacksize{t_1}}));\\
\end{align*}
\begin{align*}
{} & \text{\emph{Similar for \cleaninline{IfStable} and \cleaninline{IfUnstable}}}\\
\end{align*}
-First the context is evaluated.
+The step combinator has a task as the left-hand side and a list of continuations at the right-hand side.
+First the context is evaluated ($\cschemeE{a_{f^i}}{r}$).
The context contains arguments from functions and steps that need to be preserved after rewriting.
-The evaluated context is combined with the left-hand side task value by means of a \cleaninline{.&&.} combinator to store it in the task tree so that it is available after a rewrite.
+The evaluated context is combined with the left-hand side task value by means of a \cleaninline{.&&.} combinator to store it in the task tree so that it is available after a rewrite step.
This means that the task tree is transformed as seen in \cref{lst:context_tree}.
+In this figure, the expression \cleaninline{t1 >>=. \v1->t2 >>=. \v2->...} is shown\footnote{%
+ \cleaninline{t >>=. e} is a shorthand combinator for \cleaninline{t >>* [OnStable (\_->true) e].}}.
+Then, the right-hand side list of continuations is converted to an expression using $\mathcal{S}$.
+\todo[inline]{Beter uitleggen?}
\begin{figure}
\begin{subfigure}{.5\textwidth}
\end{lstClean}
\subsection{Shared data sources}\label{lst:imp_sds}
-The compilation scheme for \gls{SDS} definitions is a trivial extension to $\mathcal{F}$ since there is no code generated as seen below.
+The compilation scheme for \gls{SDS} definitions is a trivial extension to $\mathcal{F}$.
+While there is no code generated, metadata is added to the compiler state identifying the \gls{SDS}, this is seen later in \cref{lst:comp_sds}.
\begin{align*}
\cschemeF{\text{\cleaninline{sds}}~x=i~\text{\cleaninline{In}}~m} & =
The second phase performs one execution step for all tasks that wish for it.
Tasks are ordered in a priority queue ordered by the time a task needs to execute, the \gls{RTS} selects all tasks that can be scheduled, see \cref{sec:scheduling} for more details.
Execution of a task is always an interplay between the interpreter and the rewriter.
+\todo[inline]{ik denk dat die rewriter een paar woorden uitleg kan gebruiken.
+The rewriter scans the current task tree and tries to reqrite it. Expressions in the tree are evaluated by the interpreter.\ o.i.d.}
When a new task is received, the main expression is evaluated to produce a task tree.
A task tree is a tree structure in which each node represents a task combinator and the leaves are basic tasks.
If a task is not initialised yet, i.e.\ the pointer to the current task tree is still null, the byte code of the main function is interpreted.
-The main expression always produces a task tree.
+The main expression of \gls{MTASK} programs always produces a task tree.\todo[inline]{note dat mtask programmas altijd taken zijn, je kunt niet een niet-taak expressie opsturen naar een device}
Execution of a task consists of continuously rewriting the task until its value is stable.
Rewriting is a destructive process, i.e.\ the rewriting is done in place.
Take for example a blink task for which the code is shown in \cref{lst:blink_code}.
\begin{lstClean}[caption={Code for a blink program.},label={lst:blink_code}]
-fun \blink=(\st->delay (lit 500) >>|. writeD d3 st >>=. blink o Not)
+declarePin D13 PMOutput \ledPin->
+fun \blink=(\st->delay (lit 500) >>|. writeD ledPin st >>=. blink o Not)
In {main = blink true}
\end{lstClean}
When \cleaninline{writeD} becomes stable, the written value is the task value that is observed by the right-hand side of the \cleaninline{>>=.} combinator.
This will call the interpreter to evaluate the expression, now that the argument of the function is known.
The result of the function is again a task tree, but now with different arguments to the tasks, e.g.\ the state in \cleaninline{writeD} is inversed.
+\todo[inline]{Beter uitleggen dat \cleaninline{>>\|.} eigenlijk een step is en dat het natuurlijk eigenlijk twee trees zijn.}
\begin{figure}
\centering
repositories / phd-thesis.git / blobdiff