\subsection{Execution}
The second phase consists of performing 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 be executed, the \gls{RTS} selects all tasks that can be scheduled, see \cref{sec:scheduling} for more details.
-A task is stored below the stack and its complete state is a \gls{CLEAN} record contain most importantly the task id, a pointer to the task tree in the heap (null if not initialised yet), the current task value, the configuration of \glspl{SDS}, the configuration of peripherals, the byte code and some scheduling information.
+Execution of a task is always an interplay between the interpreter and the \emph{rewriter}.
If a task is not initialized 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.
+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.
The rewriting engine uses the interpreter when needed, e.g.\ to calculate the step continuations.
The rewriter and the interpreter use the same stack to store intermediate values.
Rewriting steps are small so that interleaving results in seemingly parallel execution.
\caption{Memory layout}\label{fig:memory_layout}
\end{figure}
+A task is stored below the stack and its complete state is a \gls{CLEAN} record contain most importantly the task id, a pointer to the task tree in the heap (null if not initialised yet), the current task value, the configuration of \glspl{SDS}, the configuration of peripherals, the byte code and some scheduling information.
+
In memory, task data grows from the bottom up and the interpreter stack is located directly on top of it growing in the same direction.
As a consequence, the stack moves when a new task is received.
This never happens within execution because communication is always processed before execution.
-Values in the interpreter are always stored on the stack, even tuples.
+Values in the interpreter are always stored on the stack.
+Compound data types are stored unboxed and flattened.
Task trees grow from the top down as in a heap.
This approach allows for flexible ratios, i.e.\ many tasks and small trees or few tasks and big trees.
For task trees---stored in the heap---the \gls{RTS} already marks tasks and task trees as trash during rewriting so the heap can be compacted in a single pass.
This is possible because there is no sharing or cycles in task trees and nodes contain pointers pointers to their parent.
-\todo{plaa\-tje van me\-mo\-ry hier}
+\todo{plaa\-tje van me\-mo\-ry hier uitbreiden}
\section{Compiler}
\subsection{Instruction set}
The instruction set is a fairly standard stack machine instruction set extended with special \gls{TOP} instructions.
+
\Cref{lst:instruction_type} shows the \gls{CLEAN} type representing the instruction set of which \cref{tbl:instr_task} gives detailed semantics.
Type synonyms are used to provide insight on the arguments of the instructions.
One notable instruction is the \cleaninline{MkTask} instruction, it allocates and initialises a task tree node and pushes a pointer to it on the stack.
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 generic programming library or compiler support that includes a lot of metadata in the record and constructor nodes.
-
\section{Conclusion}
-\todo[inline]{conclusion}
+%\todo[inline]{conclusion}
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff