-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
-sense that the \gls{C}-view does. \Glspl{Task} used with the \gls{C}-view are a
-main program that executes code and launches \glspl{Task}. It was also possible
-to just have a main program. The current \gls{mTask}-system only supports main
-programs. Sending a \gls{Task} always goes together with choosing a scheduling
-strategy. This strategy can be one of the following three strategies as
-reflected in the \CI{MTTask} message type.
-
-\begin{itemize}
- \item\CI{OneShot}
-
- \CI{OneShot} takes no parameters and means that the \gls{Task} will run
- once and will then be removed automatically. This type of scheduling
- could be useful, for example, in retrieving sensor information on
- request of a user.
- \item\CI{OnInterval}
-
- \CI{OnInterval} has the number of milliseconds to wait in between
- executions as a parameter. \Glspl{Task} running with this scheduling
- method are executed at predetermined intervals.
- \item\CI{OnInterrupt}
-
- The last scheduling method is running \glspl{Task} on a specific
- interrupt. Unfortunatly, due to time constraints and focus, none of the
- current client implementations support this. Interrupt scheduling is
- useful for \glspl{Task} that have to react on a certain type of
- hardware event such as the press of a button.
-\end{itemize}
-
-\section{\gls{SDS} semantics}
-\Gls{mTask}-\glspl{SDS} on a client are available on the server as in the form
-of regular \gls{iTasks}-\glspl{SDS}. However, the same freedom that an
-\gls{SDS} has in the \gls{iTasks}-system 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 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 is made to notify them
-of the update. \glspl{SDS} can update often and the update might not be the
-final value it will get. Implementing the same functionality on the \gls{mTask}
-client would result in a lot of expensive unneeded bandwidth usage. Therefore
-a device must publish the \gls{SDS} explicitly to save bandwidth.
-
-To add this functionality, the \CI{sds} class could be extended. However, this
-would result in having to update all existing views that use the \CI{sds}
-class. Therefore, an extra class is added that contains the extra
-functionality. Programmers can choose to implement it for existing views in the
-future but are not obliged to. The publication function has the following
-signature:
-\begin{lstlisting}[caption={The \texttt{sdspub} class}]
-class sdspub v where
- pub :: (v t Upd) -> v t Expr | type t
-\end{lstlisting}
-
-\section{Bytecode compilation view}\label{sec:compiler}
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
\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 expressive power as possible while
-keeping all instruction within one byte.
+kept large, but the number of instructions stays under $255$ to get as much
+expressive power while keeping all instruction within one byte.
The interpreter running in the client is a stack machine. The virtual
instruction \CI{BCLab} is added to allow for an easy implementation of jumping.
\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 \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
-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). 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 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}.
\begin{lstlisting}[label={lst:assignmentview},%
caption={Bytecode view implementation for assignment.}]
# newsdss = difference newstate.sdss oldstate.sdss
= ([MTSds sdsi e\\{sdsi,sdsval=e}<-newsdss] ++ [MTTask interval bc], newstate)
\end{lstlisting}
-
-\section{Examples}
-The thermostat example given previously in Listing~\ref{lst:exmtask} would be
-compiled to the following code. The left column indicates the
-position in the program memory.
-
-\begin{lstlisting}[caption={Thermostat bytecode},language=c]
- 1-2 : BCAnalogRead (Analog A0)
- 3-6 : BCPush (Int 50)
- 7 : BCGre
- 8-9 : BCJmpF 17 //Jump to else
-10-12: BCPush (Bool 1)
-13-14: BCDigitalWrite (Digital D0)
-15-16: BCJmp 21 //Jump to end of if
-17-19: BCPush (Bool 0) //Else label
-20 : BCDigitalWrite (Digital D0)
-\end{lstlisting}
repositories / msc-thesis1617.git / blobdiff