\end{figure}
\section{Compiler}\label{sec:compiler_imp}
-%The byte code compiler for \gls{MTASK} is an interpretation of the \gls{MTASK} language.
-%In order to compile terms, instances for all \gls{MTASK} type classes are required for the \cleaninline{:: BCInterpret a} type.
-%Terms in \gls{MTASK} are constructed and compiled at run time but type checked at compile time in the host language \gls{CLEAN}.
-%The compiled tasks are sent to the device for interpretation, a detailed overview of the execution process is found in \cref{sec:compiler_rts}.
-%The result of compilation is the byte code, and some metadata regarding the used peripherals and \glspl{SDS}.
-%Interpreting the byte code only uses the stack, hence, all data types are unboxed.
-%
-%The heap is only used to store the task trees that
-%
-%The byte code is interpreted by the interpreter
-%In order to make it work on resource-constrained microcontrollers, some properties of the language are strictly enforced.
-%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)
-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.}
+The byte code compiler for \gls{MTASK} is an interpretation of the \gls{MTASK} language.
+In order to compile terms, instances for all \gls{MTASK} type classes are required for the \cleaninline{:: BCInterpret a} type.
+Terms in \gls{MTASK} are constructed and compiled at run time, but type checked at compile time in the host language \gls{CLEAN}.
+The compiled tasks are sent to the device for interpretation.
+The result of the compilation is the byte code and some metadata regarding the used peripherals and \glspl{SDS}.
+The compilation target is the interpreter of the \gls{MTASK} \gls{RTS}.
+In order to keep the hardware requirements down, all expressions are evaluated on a stack.
+Rewriting of tasks uses the same stack and also a heap.
+The heap usage is minimised by applying aggressive memory management.
+A detailed overview of the \gls{RTS} including the interpreter and rewriter is found in \cref{sec:compiler_rts}.
\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.
\begin{table}
\centering
- \caption{An overview of the compilation schemes.}
+ \caption{An overview of the compilation rules.}
\begin{tabularx}{\linewidth}{l X}
\toprule
Scheme & Description\\
\midrule
- $\cschemeE{e}{r}$ & Produces the value of expression $e$ given the context $r$ and pushes it on the stack.
- The result can be a basic value or a pointer to a task.\\
- $\cschemeF{e}$ & Generates the bytecode for functions.\\
- $\cschemeS{e}{r}{w} $ & Generates the function for the step continuation given the context $r$ and the width $w$ of the left-hand side task value.\\
+ $\cschemeE{e}{r}$ & Generates code for expressions given the context $r$\\
+ $\cschemeF{e}$ & Generates the code for functions.\\
+ $\cschemeS{e}{r}{w} $ & Generates the code for the step continuations given the context $r$ and the width $w$ of the left-hand side task value.\\
\bottomrule
\end{tabularx}
\end{table}
Values are always placed on the stack; tuples and other compound data types are unpacked.
Function calls, function arguments and tasks are also compiled using $\mathcal{E}$ but their compilations is explained later.
+\begingroup
+\allowdisplaybreaks%
\begin{align*}
\cschemeE{\text{\cleaninline{lit}}~e}{r} & = \text{\cleaninline{BCPush (bytecode e)}};\\
\cschemeE{e_1\mathbin{\text{\cleaninline{+.}}}e_2}{r} & = \cschemeE{e_1}{r};
{} & \text{\emph{Where $w_l$ is the width of the left and, $w_r$ of the right value}}\\
{} & \text{\emph{similar for other unboxed compound data types}}\\
\end{align*}
+\endgroup
Translating $\mathcal{E}$ to \gls{CLEAN} code is very straightforward, it basically means writing the instructions to the writer monad.
Almost always, the type of the interpretation is not used, i.e.\ it is a phantom type.
It pops arguments from the stack according to the given task type.
The following extension of $\mathcal{E}$ shows this compilation scheme (except for the step combinator, explained in \cref{ssec:step}).
+\begingroup
+\allowdisplaybreaks%
\begin{align*}
\cschemeE{\text{\cleaninline{rtrn}}~e}{r} & =
\cschemeE{e}{r};
\cschemeE{e_2}{r};
\text{\cleaninline{BCMkTask BCAnd}};\\
\end{align*}
+\endgroup%
-This translates to Clean code by writing the correct \cleaninline{BCMkTask} instruction as exemplified in \cref{lst:imp_ret}.
+This compilation scheme translates to Clean code by first writing the arguments and then the correct \cleaninline{BCMkTask} instruction.
+This is shown for the \cleaninline{.&&.} task in \cref{lst:imp_ret}.
\begin{lstClean}[caption={The byte code interpretation implementation for \cleaninline{rtrn}.},label={lst:imp_ret}]
-instance rtrn BCInterpret
-where
- rtrn m = m >>| tell` [BCMkTask (bcstable m)]
+instance .&&. BCInterpret where
+ (.&&.) l r = l >>| r >>| tell` [BCMkTask BCTAnd]
\end{lstClean}
\subsection{Sequential combinator}\label{ssec:step}
//Return width (always 1, a task pointer)
(Just one)
>>| modify (\s->{s & bcs_context=ctx})
- >>| tell` [BCMkTask (instr rhswidth funlab)]
-
+ >>| tell` [BCMkTask (instr rhswidth funlab)][+\pagebreak+]
toContFun :: JumpLabel UInt8 -> BCInterpret a
toContFun steplabel contextwidth
= foldr tcf (tell` [BCPush fail]) cont
For this, an \cleaninline{BCInterpret} is created that emits this identifier.
When passing it to the function, the initial value of the \gls{SDS} is returned.
In the case of a local \gls{SDS}, this initial value is stored as a byte code encoded value in the state and the compiler continues with the rest of the program.
-
-\begin{align*}
- \cschemeF{\text{\cleaninline{sds}}~x=i~\text{\cleaninline{In}}~m} & =
- \cschemeF{m};\\
-\end{align*}
-
The \gls{SDS} access tasks have a compilation scheme similar to other tasks (see \cref{ssec:scheme_tasks}).
The \cleaninline{getSds} task just pushes a task tree node with the \gls{SDS} identifier embedded.
The \cleaninline{setSds} task evaluates the value, lifts that value to a task tree node and creates \pgls{SDS} set node.
\begin{align*}
+ \cschemeF{\text{\cleaninline{sds}}~x=i~\text{\cleaninline{In}}~m} & =
+ \cschemeF{m};\\
+ \\
\cschemeE{\text{\cleaninline{getSds}}~s}{r} & =
- \text{\cleaninline{BCMkTask}} (\text{\cleaninline{BCSdsGet}} s);\\
+ \text{\cleaninline{BCMkTask}}~(\text{\cleaninline{BCSdsGet}}~s);\\
\cschemeE{\text{\cleaninline{setSds}}~s~e}{r} & =
\cschemeE{e}{r};
\text{\cleaninline{BCMkTask BCStable}}_{\stacksize{e}};\\
- {} & \mathbin{\phantom{=}} \text{\cleaninline{BCMkTask}} (\text{\cleaninline{BCSdsSet}} s);\\
+ {} & \mathbin{\phantom{=}} \text{\cleaninline{BCMkTask}}~(\text{\cleaninline{BCSdsSet}}~s);\\
\end{align*}
\Cref{lst:comp_sds} shows the implementation of the \cleaninline{sds} type class.
repositories / phd-thesis.git / blobdiff