-Some example \gls{mTask}-\glspl{Task} using almost all of their functionality
-are shown in Listing~\ref{lst:exmtask}. The \gls{mTask}-\glspl{Task} shown in
-the example do not belong to a particular view and therefore are of the type
-\CI{View t r}. The \CI{blink} \gls{mTask} show the classic \gls{Arduino}
-blinking led application that blinks a certain \gls{LED} every second. The
-\CI{thermostat} expression will enable a digital pin powering a cooling fan
-when the analog pin representing a temperature sensor is too high.
-\CI{thermostat`} shows the same expression but now using the assignment style
-\gls{GPIO} technique. The \CI{thermostat} example also shows that it is not
-necessary to run everything as a \CI{task}. The main program code can also just
-consist of the contents of the root \CI{main} itself.
+Some example \gls{mTask}-\glspl{Task} --- using almost all of their
+functionality --- are shown in Listing~\ref{lst:exmtask}. The
+\gls{mTask}-\glspl{Task} shown in the example do not belong to a particular
+view and therefore are of the type \CI{View t r}. The \CI{blink} \gls{mTask}
+show the classic \gls{Arduino} blinking led application that blinks a certain
+\gls{LED} every second. The \CI{thermostat} expression will enable a digital
+pin powering a cooling fan when the analog pin representing a temperature
+sensor is too high. \CI{thermostat`} shows the same expression but now using
+the assignment style \gls{GPIO} technique. The \CI{thermostat} example also
+shows that it is not necessary to run everything as a \CI{task}. The main
+program code can also just consist of the contents of the root \CI{main}
+itself.
\begin{lstlisting}[%
label={lst:exmtask},caption={Some example \gls{mTask}-\glspl{Task}}]
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.
:: 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
\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}}]
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))
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
+All assignable types compile to an \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
+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}
-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.
+As an example for the bytecode compilation the following listing shows the
+thermostat example given in Listing~\ref{lst:exmtask} compiled to bytecode.
+The left column indicates the position in the program memory.
\begin{lstlisting}[caption={Thermostat bytecode},language=c]
1-2 : BCAnalogRead (Analog A0)
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
+15-16: BCJmp 21 //Jump to endif
17-19: BCPush (Bool 0) //Else label
20 : BCDigitalWrite (Digital D0)
+21 : //Endif label
+\end{lstlisting}
+
+The factorial function can be expressed as an \gls{mTask}-\gls{Task} and uses
+the \CI{sds} and the \CI{return} functionality. Typically this \gls{Task} is
+called with the \CI{OnInterval} scheduling strategy and will calculate the
+factorial after which is will return. The following listings shows the actual
+\gls{mTask} and the generated messages followed by the actual bytecode in a
+readable form.
+
+\begin{lstlisting}[caption={Faculty as an \gls{mTask}-\gls{Task}}]
+factorial :: Int -> Main (ByteCode () Stmt)
+factorial i = sds \y=i In
+ namedsds \x=1 Named "result" In
+ {main =
+ IF (y <=. lit 1) (
+ pub x :. retrn
+ ) (
+ x =. x *. y :. y =. y -. lit 1
+ )}
+
+//Generating the actual messages with:
+//toMessages (OnInterval 500) (factorial 5) zero
+//[MTSds 2 (BCValue 5), MTSds 1 (BCValue 1), MTTask (OnInterval 500) ...]
+\end{lstlisting}
+
+\begin{lstlisting}[label={lst:actualbc},%
+ caption={The resulting bytecode for the factorial function},language=c]
+ 0-2 : BCSdsFetch 1
+ 3-6 : BCPush i\d0\d1
+ 7 : BCLeq
+ 8-9 : BCJmpF 16 //Jump to else
+10-12: BCSdsPublish 2 ("result")
+13 : BCReturn
+14-15: BCJmp 37 //Jump to endif
+16-18: BCSdsFetch 2 ("result") //Else label
+19-21: BCSdsFetch 1
+22 : BCMul
+23-25: BCSdsStore 2 ("result")
+26-28: BCSdsFetch 1
+29-32: BCPush i\d0\d1
+33 : BCSub
+34-36: BCSdsStore 1
+37 : //Endif label
\end{lstlisting}
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. Note that
-this means that the \gls{SDS} value on the device can be different compared to
-the value of the same \gls{SDS} on the server.
+simply because it needs to be representable on clients. Also, not all \gls{SDS}
+types are possible to have on a device. 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. Note that this means that
+the \gls{SDS} value on the device can be different compared to the value of the
+same \gls{SDS} on the server.
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}
\usepackage{pgf-umlsd} % Connection diagrams
\usepackage{graphicx} % Graphics
\usepackage{epstopdf} % Eps graphics
-\usepackage{etoolbox} % Todo notes
+\usepackage{etoolbox} % Patch chapter command
\patchcmd{\chapter}{plain}{headings}{}{}
repositories / msc-thesis1617.git / commitdiff