-The \glspl{Task} suitable for a client are called \glspl{mTask} and are written
-in the aforementioned \gls{mTask}-\gls{EDSL}. Some functionality of the
-original \gls{mTask}-\gls{EDSL} will not be used in this system. Conversely,
-some functionality needed was not available in the existing \gls{EDSL}. Due to
-the nature of class based shallow embedding this obstacle is 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.
+The \glspl{Task} suitable for a client are called \gls{mTask}-\gls{Task} and
+are written in the aforementioned \gls{mTask}-\gls{EDSL}. Some functionality of
+the original \gls{mTask}-\gls{EDSL} will not be used in this system.
+Conversely, some functionality needed was not available in the existing
+\gls{EDSL}. Due to the nature of class based shallow embedding this obstacle is
+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{\gls{Task} Semantics}
The current \gls{mTask} engine for devices does not support \glspl{Task} in the
\Glspl{SDS} on a client are available on the server as well as regular
\glspl{SDS}. However, the same freedom is not given for \glspl{SDS} that
reside on the client. Not all types are suitable to be located on a client,
-simply because it needs to be serializable and representable on clients.
+simply because it needs to be representable on clients.
Moreover, \glspl{SDS} behave a little different in an \gls{mTask} device
compared to in the \gls{iTasks} system. In an \gls{iTasks} system, when the
\gls{SDS} is updated, a broadcast to all watching \glspl{Task} in the system
\end{lstlisting}
\section{Bytecode compilation view}\label{sec:compiler}
-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 view is
-added to the \gls{mTask}-system encapsulated in the type \CI{ByteCode}. As
+The \gls{mTask}-\glspl{Task} 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 view
+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
\subsection{Instruction Set}\label{sec:instruction}
The instruction set is given in Listing~\ref{bc:instr}. The instruction set is
-kept large, but under $255$, to get as much expressieve power as possible while
+kept large, but under $255$, to get as much expressive power as possible while
keeping all instruction within one byte.
The interpreter running in the client is a stack machine. The virtual
noOp = tell` [BCNop]
\end{lstlisting}
-The semantics for the \glspl{mTask} 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 indefinitly, 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.
+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.
\end{lstlisting}
All assignable types compile to a \gls{RWST} which writes the specific fetch
-instruction(s). For example, using a \gls{SDS} always results in an expression
+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 \gls{RWST} that
always writes one \CI{BCSdsFetch} instruction with the correctly embedded
\gls{SDS}. Assigning to an analog pin will result in the \gls{RWST} containing
17-19: BCPush (Bool 0) //Else label
20 : BCDigitalWrite (Digital D0)
\end{lstlisting}
-\todo{More elaborate example}
repositories / msc-thesis1617.git / blobdiff