From: Mart Lubbers Date: Thu, 29 Jun 2017 21:48:21 +0000 (+0200) Subject: add bigger mtask example X-Git-Tag: hand-in~30 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=d66b8c6bae6fde77e7ba53759f862364a9505ace;p=msc-thesis1617.git add bigger mtask example --- diff --git a/mtask.examples.tex b/mtask.examples.tex index 925b66b..db15f5f 100644 --- a/mtask.examples.tex +++ b/mtask.examples.tex @@ -1,14 +1,15 @@ -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}}] diff --git a/mtaskext.bytecode.tex b/mtaskext.bytecode.tex index 111be6f..887a6b5 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. @@ -30,13 +30,14 @@ same detection if necessary. :: 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 @@ -188,11 +189,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 +203,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,11 +214,11 @@ 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 +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} diff --git a/mtaskext.examples.tex b/mtaskext.examples.tex index 66c2466..57782d8 100644 --- a/mtaskext.examples.tex +++ b/mtaskext.examples.tex @@ -1,6 +1,6 @@ -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) @@ -9,7 +9,51 @@ position in the program memory. 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} diff --git a/mtaskext.sdssem.tex b/mtaskext.sdssem.tex index 0107712..b0b8fa6 100644 --- a/mtaskext.sdssem.tex +++ b/mtaskext.sdssem.tex @@ -2,16 +2,17 @@ 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} diff --git a/thesis.pre b/thesis.pre index ef044a4..1b2af12 100644 --- a/thesis.pre +++ b/thesis.pre @@ -15,7 +15,7 @@ \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}{}{}