X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=results.mtask.tex;h=1b46df106c84f958e62eb7ab145d1c86f0510e5f;hb=c7fa2f10a5c049e2ae70405630857c7873778899;hp=0c50555fb091083b655be25ba97b0e36ee5680b7;hpb=4c3c9734d91c19e41eb4424944247adad214d188;p=msc-thesis1617.git diff --git a/results.mtask.tex b/results.mtask.tex index 0c50555..1b46df1 100644 --- a/results.mtask.tex +++ b/results.mtask.tex @@ -1,21 +1,72 @@ -Some functionality of the original \gls{mTask}-\gls{EDSL} will not be used in -this extension \gls{EDSL}. Conversely, some functionality needed was not -available in the existing \gls{EDSL}. Due to the nature of class based shallow -embedding this obstacle is very 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 \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 extension \gls{EDSL}. +Conversely, some functionality needed was not available in the existing +\gls{EDSL}. Due to the nature of class based shallow embedding this obstacle is +very 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{Semantics} -\todo{semantics} +The current \gls{mTask} engine for devices does not support \glspl{Task} in the +sense that the \gls{C}-view it does. \Glspl{Task} used with the \gls{C}-view +are a main program that runs some \gls{Task}. \glspl{Task} in the new system +are \CI{Main} objects with a program inside that does not contain \glspl{Task} +but are a \gls{Task} as a whole. 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}. + +\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 usefull to for example retrieving sensor information on + request of a user. + \item\CI{OnInterval} + + \CI{OnInterval} has as a parameter the number of milliseconds to wait + in between executions. \Glspl{Task} running with this scheduling method + are executed every fixed interval. + \item\CI{OnInterrupt} + + The last scheduling method is running \glspl{Task} on a specific + interrupt. None of the current implementation implement this. However, + registering interrupts on for example the \gls{Arduino} is very + straightforward. Interrupt scheduling is usefull for \glspl{Task} that + have to react on a certain type of hardware event such as the press of + a button. +\end{itemize} + +\subsection{\glspl{SDS}} +\Glspl{SDS} on a client are available on the server as well. However, the same +freedom is not given on the \glspl{SDS} that reside on the client. Not all +types are suitable to be located on a client. Moreover, \glspl{SDS} behave a +little bit differently on an \gls{mTask} device than in the \gls{iTasks} +system. In an \gls{iTasks} system, when the \gls{SDS} is updated, a broadcast +to everyone in the system watching is made to notify them of an update. +\glspl{SDS} on the device can update very often and the update might not be the +final value it will get. 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. The existing views can choose to implement it 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} +\section{Bytecode compilation}\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 called \CI{ByteCode}. As shown in -Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST} that -writes bytecode instructions (\CI{BC}) while carrying around a \CI{BCState}. -The state is kept between devices and contains fresh variable names and a -register of shares used. +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}) 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 register of shares used. Types implementing the \gls{mTask} classes must have two free type variables. Therefore the \gls{RWST} is wrapped with a constructor and two phantom type @@ -43,8 +94,8 @@ accordingly. , sdsval :: BCValue } :: BCState = - { freshl :: [Int] - , freshs :: [Int] + { freshl :: Int + , freshs :: Int , sdss :: [BCShare] } @@ -158,7 +209,7 @@ since the labels are resolved to real addresses later on anyways. \begin{lstlisting}[label={lst:controlflow},% caption={Bytecode view for \texttt{arith}}] -freshlabel = get >>= \st=:{freshl=[fr:frs]}->put {st & freshl=frs} >>| pure fr +freshlabel = get >>= \st=:{freshl}->put {st & freshl=freshl+1} >>| pure freshl instance If ByteCode Stmt Stmt Stmt where If b t e = BCIfStmt b t e instance If ByteCode e Stmt Stmt where If b t e = BCIfStmt b t e @@ -187,7 +238,7 @@ implementation is shown in Listing~\ref{lst:shareview}. \begin{lstlisting}[label={lst:shareview},% caption={Bytecode view for \texttt{arith}}] -freshshare = get >>= \st=:{freshl=[fr:frs]}->put {st & freshl=frs} >>| pure fr +freshshare = get >>= \st=:{freshs}->put {st & freshs=freshs+1} >>| pure freshs instance sds ByteCode where sds f = {main = BC (freshshare @@ -196,6 +247,7 @@ instance sds ByteCode where >>= \(v In bdy)->modify (addSDS sds v) >>| unBC (unMain bdy)) } +instance sdspub ByteCode where pub (BC x) = BC (censor (\[BCSdsFetch s]->[BCSdsPublish s]) x) addSDS sds v s = {s & sdss=[{sds & sdsval=BCValue v}:s.sdss]} @@ -271,3 +323,51 @@ position in the program memory. 17-19: BCPush (Bool 0) //Else label 20 : BCDigitalWrite (Digital D0) \end{lstlisting} + +\section{Interpreter} +The client contains an interpreter to execute a \gls{Task}'s bytecode. + +First some preparatory work is done. The stack will be initialized and the +program counter and stack pointer are set to zero and the bottom respectively. +Then the interpreter executes one step at the time while the program counter is +smaller than the program length. The code for this is listed in +Listing~\ref{lst:interpr}. One execution step is basically a big switch +statement going over all possible bytecode instructions. Some instructions are +detailed upon in the listing. The \CI{BCPush} instruction is a little more +complicated in real life because some decoding will take place as not all +\CI{BCValue}'s are of the same length. + +\begin{lstlisting}[language=C,label={lst:interpr},% + caption={Rough code outline for interpretation}] +#define f16(p) program[pc]*265+program[pc+1] + +void run_task(struct task *t){ + uint8_t *program = t->bc; + int plen = t->tasklength; + int pc = 0; + int sp = 0; + while(pc < plen){ + switch(program[pc++]){ + case BCNOP: + break; + case BCPUSH: + stack[sp++] = pc++ //Simplified + break; + case BCPOP: + sp--; + break; + case BCSDSSTORE: + sds_store(f16(pc), stack[--sp]); + pc+=2; + break; + // ... + case BCADD: trace("add"); + stack[sp-2] = stack[sp-2] + stack[sp-1]; + sp -= 1; + break; + // ... + case BCJMPT: trace("jmpt to %d", program[pc]); + pc = stack[--sp] ? program[pc]-1 : pc+1; + break; +} +\end{lstlisting}