\subsection{Shared data sources}\label{lst:imp_sds}
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}.
+While there is no code generated in the definition, the byte code compiler is storing all \gls{SDS} data in the \cleaninline{bcs_sdses} field in the compilation state.
+Regular \glspl{SDS} are stored as \cleaninline{Right String255} values.
+The \glspl{SDS} are typed as functions in the host language, so an argument for this function must be created that represents the \gls{SDS} on evaluation.
+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} & =
{} & \mathbin{\phantom{=}} \text{\cleaninline{BCMkTask}} (\text{\cleaninline{BCSdsSet}} s);\\
\end{align*}
-While there is no code generated in the definition, the byte code compiler is storing all \gls{SDS} data in the \cleaninline{bcs_sdses} field in the compilation state.
-Regular \glspl{SDS} are stored as \cleaninline{Right String255} values.
-The \glspl{SDS} are typed as functions in the host language, so an argument for this function must be created that represents the \gls{SDS} on evaluation.
-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.
-
\Cref{lst:comp_sds} shows the implementation of the \cleaninline{sds} type class.
First, the initial \gls{SDS} value is extracted from the expression by bootstrapping the fixed point with a dummy value.
This is safe because the expression on the right-hand side of the \cleaninline{In} is never evaluated.
\caption{Memory layout in the \gls{MTASK} \gls{RTS}.}\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.
+A task is stored below the stack and it consists of 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 is possible because there is no sharing or cycles in task trees and nodes contain pointers to their parent.
-\section{C code generation}\label{sec:ccodegen}
+\section{C code generation for communication}\label{sec:ccodegen}
All communication between the \gls{ITASK} server and the \gls{MTASK} server is type parametrised.
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.
\subsection{Client}
The \gls{RTS} of the \gls{MTASK} system runs on resource-constrained microcontrollers and is implemented in portable \ccpp{}.
In order to achieve more interoperation safety, the communication between the server and the client is automated, i.e.\ the serialisation and deserialisation code in the \gls{RTS} is generated.
+\todo[inline]{Dit naar voren halen naar 7.4.0?}
The technique used for this is very similar to the technique shown in \cref{chp:first-class_datatypes}.
However, instead of using template metaprogramming, a feature \gls{CLEAN} lacks, generic programming is used also as a two-stage rocket.
In contrast to many other generic programming systems, \gls{CLEAN} allows for access to much of the metadata of the compiler.
repositories / phd-thesis.git / blobdiff