X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;ds=sidebyside;f=results.mtask.tex;h=8c220151467cc8a0a7ae13b68ee29b56a21d6cf1;hb=aad24fbc3e6d51559228eb0196536fc00ab58686;hp=8b0fb20ea551cc3b22c00efbe87392d13c2674cf;hpb=d11a7941da4024ec8ff9ef6afaebb6eb9d2c6ed4;p=msc-thesis1617.git

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}