X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=mtaskext.bytecode.tex;h=fd5feee518ef367f8417ef521727c96532078406;hb=4f4b21c04bc99e4e7d55a1dcbedbd371d97b2a05;hp=111be6fd5bfc4f479c2365076c09736efb314cb2;hpb=6548a5ec9ce8e0df67fc4019625ab5238eb1bf71;p=msc-thesis1617.git

diff --git a/mtaskext.bytecode.tex b/mtaskext.bytecode.tex
index 111be6f..fd5feee 100644
--- a/mtaskext.bytecode.tex
+++ b/mtaskext.bytecode.tex
@@ -4,7 +4,7 @@ is added to the \gls{mTask}-system encapsulated in the type \CI{ByteCode}. As
 shown in Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST}
 that writes bytecode instructions (\CI{BC}, Subsection~\ref{sec:instruction})
 while carrying around a \CI{BCState}. The state is kept between compilations
-and is unique to a device.  The state contains fresh variable names and a
+and is unique to a device. The state contains fresh variable names and a
 register of \glspl{SDS} that are used.
 
 Types implementing the \gls{mTask} classes must have two free type variables.
@@ -24,19 +24,23 @@ 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 single byte prefixes to
 detect the type of the value. The devices know these prefixes and can apply the
-same detection if necessary.
+same detection if necessary. Note that \CI{BCValue} uses existentially
+quantified type variables and therefore it is not possible to derive class
+instances such as \CI{iTasks}. Tailor-made instances for these functions have
+been made.
 
 \begin{lstlisting}[label={lst:bcview},caption={Bytecode view}]
 :: ByteCode a p = BC (RWS () [BC] BCState ())
 :: BCValue = E.e: BCValue e & mTaskType, TC e
 :: BCShare =
-	{ sdsi :: Int
-	, sdsval :: BCValue
+	{ sdsi    :: Int
+	, sdsval  :: BCValue
+	, sdsname :: String
 	}
 :: BCState = 
 	{ freshl :: Int
 	, freshs :: Int
-	, sdss :: [BCShare]
+	, sdss   :: [BCShare]
 	}
 
 class toByteCode a :: a -> String
@@ -170,12 +174,12 @@ instance noOp ByteCode where
 The semantics for the \gls{mTask}-\glspl{Task} bytecode view are different from
 the semantics of the \gls{C} view. \glspl{Task} in the \gls{C} view can start
 new \glspl{Task} or even start themselves to continue, while in the bytecode
-view, \glspl{Task} run indefinitely, one-shot or on interrupt. To allow interval
-and interrupt \glspl{Task} to terminate, a return instruction is added. This
-class was not available in the original system and is thus added. It just
-writes a single instruction so that the interpreter knows to stop execution.
-Listing~\ref{lst:return} shows the classes and implementation for the return
-expression.
+view, \glspl{Task} run indefinitely, one-shot or on interrupt. To allow
+interval and interrupt \glspl{Task} to terminate, a return instruction is
+added. This class was not available in the original system and is thus added.
+It just writes a single instruction so that the interpreter knows to stop
+execution.  Listing~\ref{lst:return} shows the classes and implementation for
+the return expression.
 
 \begin{lstlisting}[label={lst:return},%
 	caption={Bytecode view for the return instruction}]
@@ -188,11 +192,13 @@ instance retrn ByteCode where
 
 \subsection{Shared Data Sources \& Assignment}
 Fresh \gls{SDS} are generated using the state and constructing one involves
-multiple steps.  First, a fresh identifier is grabbed from the state.  Then a
+multiple steps. First, a fresh identifier is grabbed from the state.  Then a
 \CI{BCShare} record is created with that identifier. A \CI{BCSdsFetch}
 instruction is written and the body is generated to finally add the \gls{SDS}
 to the actual state with the value obtained from the function. The exact
-implementation is shown in Listing~\ref{lst:shareview}.
+implementation is shown in Listing~\ref{lst:shareview}. The implementation for
+the \CI{namedsds} class is exactly the same other than that it stores the given
+name in the \CI{BCShare} structure as well.
 
 \begin{lstlisting}[label={lst:shareview},%
 	caption={Bytecode view for \texttt{arith}}]
@@ -200,7 +206,7 @@ freshshare = get >>= \st=:{freshs}->put {st & freshs=freshs+1} >>| pure freshs
 
 instance sds ByteCode where
 	sds f = {main = BC (freshshare
-			>>= \sdsi->pure {BCShare|sdsi=sdsi,sdsval=BCValue 0}
+			>>= \sdsi->pure {BCShare|sdsname="",sdsi=sdsi,sdsval=BCValue 0}
 			>>= \sds->pure (f (tell` [BCSdsFetch sds]))
 			>>= \(v In bdy)->modify (addSDS sds v)
 			>>| unBC (unMain bdy))
@@ -211,16 +217,16 @@ instance sdspub ByteCode where
 addSDS sds v s = {s & sdss=[{sds & sdsval=BCValue v}:s.sdss]}
 \end{lstlisting}
 
-All assignable types compile to a \gls{RWST} which writes the specific fetch
-instruction(s). For example, using an \gls{SDS} always results in an
-expression of the form \CI{sds \x=4 In ...}. The actual \CI{x} is the
+All assignable types compile to an \gls{RWST} which writes the specific fetch
+instruction(s). For example, using an \gls{SDS} always results in % chktex 36
+an expression of the form \CI{sds \x=4 In ...}. The actual \CI{x} is the
 \gls{RWST} that always writes one \CI{BCSdsFetch} instruction with the
-correctly embedded \gls{SDS}.  Assigning to an analog pin will result in the
+correctly embedded \gls{SDS}. Assigning to an analog pin will result in the
 \gls{RWST} containing the \CI{BCAnalogRead} instruction. When the operation on
 the assignable is not a read operation from but an assign operation, the
-instruction(s) will be rewritten accordingly. This results in a \CI{BCSdsStore}
-or \CI{BCAnalogWrite} instruction respectively. The implementation for this is
-given in Listing~\ref{lst:assignmentview}.
+instruction(s) will be rewritten accordingly. This results in a %chktex 36
+\CI{BCSdsStore} or \CI{BCAnalogWrite} instruction respectively. The
+implementation for this is given in Listing~\ref{lst:assignmentview}.
 
 \begin{lstlisting}[label={lst:assignmentview},%
 	caption={Bytecode view implementation for assignment.}]