\end{figure}
\section{Compiler}\label{sec:compiler_imp}
+The byte code compiler for \gls{MTASK} is designed to generate code that runs on resource-constrained edge devices.
+There is no heap avaliable for expressions, only for tasks
\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.
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}
\includestandalone{contexttree2}
\caption{With the embedded context.}
\end{subfigure}
- \caption{Context embedded in a task tree.}%
+ \caption{Context embedded in a virtual task tree.}%
\label{lst:context_tree}
\end{figure}
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.}
+The rewriter scans the current task tree and tries to rewrite it using small-step reduction.
+Expressions in the tree are always strictly evaluated by the interpreter.
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 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}
+The main expression of \gls{MTASK} programs sent to the device fore execution always produces a task tree.
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.
\end{lstClean}
On receiving this task, the task tree is still null and the initial expression \cleaninline{blink true} is evaluated by the interpreter.
-This results in the task tree shown in \cref{fig:blink_tree}.
+This results in the task tree shown in \cref{fig:blink_tree1}.
Rewriting always starts at the top of the tree and traverses to the leaves, the basic tasks that do the actual work.
The first basic task encountered is the \cleaninline{delay} task, that yields no value until the time, \qty{500}{\ms} in this case, has passed.
-When the \cleaninline{delay} task yielded a stable value after a number of rewrites, the task continues with the right-hand side of the \cleaninline{>>\|.} combinator.
+When the \cleaninline{delay} task yielded a stable value after a number of rewrites, the task continues with the right-hand side of the \cleaninline{>>\|.} combinator by evaluating the expression (see \cref{fig:blink_tree2})\footnotemark.
+\footnotetext{\cleaninline{t1 >>\|. t2} is a shorthand for \cleaninline{t1 >>*. [IfStable id \_->t2]}.}
This combinator has a \cleaninline{writeD} task at the left-hand side that becomes stable after one rewrite step in which it writes the value to the given pin.
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.}
+The result of the call to the function is again a task tree, but now with different arguments to the tasks, e.g.\ the state in \cleaninline{writeD} is inversed.
\begin{figure}
\centering
- \includestandalone{blinktree}
- \caption{The task tree for a blink task in \cref{lst:blink_code} in \gls{MTASK}.}%
+ \begin{subfigure}[t]{.5\textwidth}
+ \includestandalone{blinktree1}
+ \caption{Initial task tree}%
+ \label{fig:blink_tree1}
+ \end{subfigure}%
+ \begin{subfigure}[t]{.5\textwidth}
+ \includestandalone{blinktree2}
+ \caption{Task tree after the delay passed}%
+ \label{fig:blink_tree2}
+ \end{subfigure}
+ \caption{The task trees for a blink task in \cref{lst:blink_code} in \gls{MTASK}.}%
\label{fig:blink_tree}
\end{figure}
\section{C code generation for communication}\label{sec:ccodegen}
-All communication between the \gls{ITASK} server and the \gls{MTASK} server is type parametrised.
+All communication between the \gls{ITASK} server and the \gls{MTASK} server is type parametrised and automated.
From the structural representation of the type, a \gls{CLEAN} parser and printer is constructed using generic programming.
Furthermore, a \ccpp{} parser and printer is generated for use on the \gls{MTASK} device.
The technique for generating the \ccpp{} parser and printer is very similar to template metaprogramming and requires a rich generic programming library or compiler support that includes a lot of metadata in the record and constructor nodes.
repositories / phd-thesis.git / blobdiff