From aad24fbc3e6d51559228eb0196536fc00ab58686 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Tue, 6 Jun 2017 10:22:47 +0200 Subject: [PATCH] add text on mTask extensions, introduce bytecode view --- results.arch.tex | 8 ++++---- results.mtask.tex | 44 +++++++++++++++++++++++++++++++++----------- 2 files changed, 37 insertions(+), 15 deletions(-) diff --git a/results.arch.tex b/results.arch.tex index 30fbc7a..87a25cb 100644 --- a/results.arch.tex +++ b/results.arch.tex @@ -150,10 +150,10 @@ function and the record is updated accordingly. \begin{figure}[H] \begin{sequencediagram} - \newthread{c}{Server} - \newinst[4]{s}{Client} - \mess{c}{MTSpec}{s} - \mess{s}{MTDevSpec d}{c} + \newthread{s}{Server} + \newinst[4]{c}{Client} + \begin{call}{s}{MTSpec}{c}{MTDevSpec} + \end{call} \end{sequencediagram} \caption{Connect a device}\label{fig:handshake} \end{figure} diff --git a/results.mtask.tex b/results.mtask.tex index 8b0fb20..8c22015 100644 --- a/results.mtask.tex +++ b/results.mtask.tex @@ -5,14 +5,34 @@ embedding this obstacle is very easy to solve. A type housing the \gls{EDSL} does not have to implement all the available classes. Moreover, classes can be added at will without interfering with the existing views. -\section{Bytecode compilation view} +\section{Bytecode compilation} The \glspl{mTask} are sent to the device in bytecode and are saved in the -memory of the device. To compile the \gls{EDSL} code to bytecode a \gls{RWST} -is used. The \gls{RWST} is a state transformer stacked on a \emph{Reader} monad -and a \emph{Writer} monad. In this case the transformer part is not used. -However, this can be done to add for example better runtime error handling. +memory of the device. To compile the \gls{EDSL} code to bytecode, a view is +added to the \gls{mTask}-system called \CI{ByteCode}. As shown in +Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST} that +writes bytecode instructions (\CI{BC}) while carrying around a \CI{BCState}. +The state is kept between devices and contains fresh variable names and a +register of shares used. -\begin{lstlisting}[language=Clean] +Types implementing the \gls{mTask} classes must have two free type variables. +Therefore the \gls{RWST} is wrapped with a constructor and two phantom type +variables are added. This means that the programmer has to unbox the +\CI{ByteCode} object to be able to use return values for the monad. Tailor made +access functions are used to achieve this with ease. The fresh variable stream +in a compiler using an \gls{RWST} is often put in to the \emph{Reader} part of +the monad. However, not all code is compiled immediately and later on the fresh +variable stream can not contain variables that were used before. Therefore this +information is put in the state which is kept between compilations. + +Not all types are suitable for usage in bytecode compiled programs. Every value +used in the bytecode view must fit in the \CI{BCValue} type which restricts +the content. Most notably, the type must be bytecode encodable. A \CI{BCValue} +must be encodable and decodable without losing type or value information. At +the moment a simple encoding scheme is used that uses a single byte prefixes to +detect which type the value is. The devices know of these prefixes and act +accordingly. + +\begin{lstlisting}[language=Clean,label={lst:bcview},caption={Bytecode view}] :: ByteCode a p = BC (RWS () [BC] BCState ()) :: BCValue = E.e: BCValue e & mTaskType, TC e :: BCShare = { @@ -37,12 +57,14 @@ instance arith ByteCode instance serial ByteCode \end{lstlisting} -\section{Bytecode compilation view for \gls{mTask}} -Compilation to bytecode +\section{Implementation} +\subsection{Helper functions} + +\subsection{Arithmetics} + +\subsection{Control Flow} -\subsection{Backend} -\todo{Aanpassingen -aan de mTask DSL} +\subsection{Shared Data Sources} \section{Semantics} -- 2.20.1