1 The
\glspl{Task
} suitable for a client are called
\glspl{mTask
} and are written
2 in the aforementioned
\gls{mTask
}-
\gls{EDSL
}. Some functionality of the
3 original
\gls{mTask
}-
\gls{EDSL
} will not be used in this system. Conversely,
4 some functionality needed was not available in the existing
\gls{EDSL
}. Due to
5 the nature of class based shallow embedding this obstacle is very easy to
6 solve. A type --- housing the
\gls{EDSL
} --- does not have to implement all the
7 available classes. Moreover, classes can be added at will without interfering
8 with the existing views.
10 \section{\gls{Task
} Semantics
}
11 The current
\gls{mTask
} engine for devices does not support
\glspl{Task
} in the
12 sense that the
\gls{C
}-view does.
\Glspl{Task
} used with the
\gls{C
}-view are a
13 main program that executes code and launches
\glspl{Task
}. It was also possible
14 to just have a main program. The current
\gls{mTask
}-system only supports main
15 programs. Sending a
\gls{Task
} always goes together with choosing a scheduling
16 strategy. This strategy can be one of the following three strategies as
17 reflected in the
\CI{MTTask
} message type.
22 \CI{OneShot
} takes no parameters and means that the
\gls{Task
} will run
23 once and will then be removed automatically. This type of scheduling
24 could be useful, for example, in retrieving sensor information on
28 \CI{OnInterval
} has as a parameter the number of milliseconds to wait
29 in between executions.
\Glspl{Task
} running with this scheduling method
30 are executed at predetermined intervals.
33 The last scheduling method is running
\glspl{Task
} on a specific
34 interrupt. None of the current client implementations support this.
35 However, registering interrupts on, for example the
\gls{Arduino
} is
36 very straightforward. Interrupt scheduling is useful for
\glspl{Task
}
37 that have to react on a certain type of hardware event such as the
41 \section{\gls{SDS
} semantics
}
42 \Glspl{SDS
} on a client are available on the server as well as regular
43 \gls{SDS
}. However, the same freedom is not given on the
\glspl{SDS
} that
44 reside on the client. Not all types are suitable to be located on a client.
45 Moreover,
\glspl{SDS
} behave a little different on an
\gls{mTask
} device
46 compared to the
\gls{iTasks
} system. In an
\gls{iTasks
} system, when the
\gls{SDS
}
47 is updated, a broadcast to everyone in the system watching is made to notify
48 them of the update.
\glspl{SDS
} can update very often and the
49 update might not be the final value it will get. This results in a lot of
50 expensive unneeded bandwidth usage. Therefore a device must publish the
51 \gls{SDS
} explicitly to save bandwidth.
53 To add this functionality, the
\CI{sds
} class could be extended. However, this
54 would result in having to update all existing views that use the
\CI{sds
}
55 class. Therefore, an extra class is added that contains the extra
56 functionality. The existing views can choose to implement it in the future but
57 are not obliged to. The publication function has the following signature:
58 \begin{lstlisting
}[caption=
{The
\texttt{sdspub
} class
}]
60 pub :: (v t Upd) -> v t Expr | type t
63 \section{Bytecode compilation view
}\label{sec:compiler
}
64 The
\glspl{mTask
} are sent to the device in bytecode and are saved in the
65 memory of the device. To compile the
\gls{EDSL
} code to bytecode, a view is
66 added to the
\gls{mTask
}-system encapsulated in the type
\CI{ByteCode
}. As
67 shown in Listing~
\ref{lst:bcview
}, the
\CI{ByteCode
} view is a boxed
\gls{RWST
}
68 that writes bytecode instructions (
\CI{BC
}) while carrying around a
69 \CI{BCState
}. The state is kept between compilations and is unique to a device.
70 The state contains fresh variable names and a register of
\glspl{SDS
} used.
72 Types implementing the
\gls{mTask
} classes must have two free type variables.
73 Therefore the
\gls{RWST
} is wrapped with a constructor and two phantom type
74 variables are added. This means that the programmer has to unbox the
75 \CI{ByteCode
} object to be able to make use of the
\gls{RWST
} functionality
76 such as return values. Tailor made access functions are used to achieve this
77 with ease. The fresh variable stream in a compiler using a
\gls{RWST
} is often
78 put into the
\emph{Reader
} part of the monad. However, not all code is compiled
79 immediately and later on the fresh variable stream cannot contain variables
80 that were used before. Therefore this information is put in the state which is
81 kept between compilations.
83 Not all types are suitable for usage in bytecode compiled programs. Every value
84 used in the bytecode view must fit in the
\CI{BCValue
} type which restricts
85 the content. Most notably, the type must be bytecode encodable. A
\CI{BCValue
}
86 must be encodable and decodable without losing type or value information. At
87 the moment a simple encoding scheme is used that uses single byte prefixes to
88 detect the type of the value. The devices know these prefixes and can apply the
89 same detection if necessary.
91 \begin{lstlisting
}[label=
{lst:bcview
},caption=
{Bytecode view
}]
92 :: ByteCode a p = BC (RWS ()
[BC
] BCState ())
93 :: BCValue = E.e: BCValue e & mTaskType, TC e
104 class toByteCode a :: a -> String
105 class fromByteCode a :: String -> a
106 class mTaskType a | toByteCode, fromByteCode, iTask, TC a
108 instance toByteCode Int, ... , UserLED, BCValue
109 instance fromByteCode Int, ... , UserLED, BCValue
111 instance arith ByteCode
113 instance serial ByteCode
116 \subsection{Instruction Set
}
117 The instruction set is given in Listing~
\ref{bc:instr
}. The instruction set is
118 kept large, but under $
255$, to get the highest expressively while keeping all
119 instruction one byte.
121 The interpreter running in the client is a stack machine. The virtual
122 instruction
\CI{BCLab
} is added to allow for an easy implementation of jumping.
123 However, this is not a real instruction and the labels are resolved to actual
124 program memory addresses in the final step of compilation to save instructions
125 and avoid label lookups at runtime.
127 \begin{lstlisting
}[label=
{bc:instr
},
%
128 caption=
{Bytecode instruction set
}]
130 | BCLab Int | BCPush BCValue | BCPop
132 | BCSdsStore BCShare | BCSdsFetch BCShare | BCSdsPublish BCShare
136 | BCAdd | BCSub | BCMul
141 | BCEq | BCNeq | BCLes | BCGre
143 //Conditionals and jumping
144 | BCJmp Int | BCJmpT Int | BCJmpF Int
148 | BCAnalogRead Pin | BCAnalogWrite Pin | BCDigitalRead Pin | BCDigitalWrite Pin
153 All single byte instructions are converted automatically using the generic
154 function
\CI{consIndex
} which returns the index of the constructor. The index
155 of the constructor is the byte value for all instructions. The last step of the
156 compilation is transforming the list of bytecode instructions to actual bytes.
158 \subsection{Helper functions
}
159 The
\CI{ByteCode
} type is just a boxed
\gls{RWST
} and that gives us access to
160 the whole range of
\gls{RWST
} functions. However, to apply a function the type
161 must be unboxed. After application the type must be boxed again. To achieve
162 this, several helper functions have been created. They are listed in
163 Listing~
\ref{lst:helpers
}. The
\CI{op
} and
\CI{op2
} function is crafted to make
164 operators that pop one or two values off the stack respectively. The
\CI{tell`
}
165 is a wrapper around the
\gls{RWST
} function
\CI{tell
} that appends the argument
166 to the
\emph{Writer
} value.
168 \begin{lstlisting
}[label=
{lst:helpers
},caption=
{Some helper functions
}]
169 op2 :: (ByteCode a p1) (ByteCode a p2) BC -> ByteCode b Expr
170 op2 (BC x) (BC y) bc = BC (x >>| y >>| tell
[bc
])
172 op :: (ByteCode a p) BC -> ByteCode b c
173 op (BC x) bc = BC (x >>| tell
[bc
])
175 tell` ::
[BC
] -> (ByteCode a p)
176 tell` x = BC (tell x)
178 unBC :: (ByteCode a p) -> RWS ()
[BC
] BCState ()
182 \subsection{Arithmetics \& Peripherals
}
183 Almost all of the code from the simple classes use exclusively helper
184 functions. Listing~
\ref{lst:arithview
} shows some implementations. The classes
185 \CI{boolExpr
} and the classes for the peripherals are implemented using the
188 \begin{lstlisting
}[label=
{lst:arithview
},caption=
{%
189 Bytecode view implementation for arithmetic and peripheral classes
}]
190 instance arith ByteCode where
191 lit x = tell`
[BCPush (BCValue x)
]
192 (+.) x y = op2 x y BCDiv
195 instance userLed ByteCode where
196 ledOn l = op l BCLedOn
197 ledOff l = op l BCLedOff
200 \subsection{Control Flow
}
201 Implementing the sequence operator is very straightforward in the bytecode
202 view. The function just sequences the two
\glspl{RWST
}. The
\emph{If
} statement
203 requires some detailed explanation since labels come into play. The
204 implementation speaks for itself in Listing~
\ref{lst:controlflow
}. First, all
205 the labels are gathered and then they are placed in the correct order in the
206 bytecode sequence. It can happen that multiple labels appear consecutively in
207 the code. This is not a problem since the labels are resolved to real addresses
210 \begin{lstlisting
}[label=
{lst:controlflow
},
%
211 caption=
{Bytecode view for
\texttt{arith
}}]
212 freshlabel = get >>=
\st=:
{freshl
}->put
{st & freshl=freshl+
1} >>| pure freshl
214 instance If ByteCode Stmt Stmt Stmt where If b t e = BCIfStmt b t e
215 instance If ByteCode e Stmt Stmt where If b t e = BCIfStmt b t e
216 instance If ByteCode Stmt e Stmt where If b t e = BCIfStmt b t e
217 instance If ByteCode x y Stmt where If b t e = BCIfStmt b t e
218 instance IF ByteCode where
219 IF b t e = BCIfStmt b t e
220 (?) b t = BCIfStmt b t (tell`
[])
221 BCIfStmt (BC b) (BC t) (BC e) = BC (
222 freshlabel >>=
\else->freshlabel >>=
\endif->
223 b >>| tell
[BCJmpF else
] >>|
224 t >>| tell
[BCJmp endif, BCLab else
] >>|
225 e >>| tell
[BCLab endif
]
227 instance noOp ByteCode where
231 \todo{Add return instruction
}
233 \subsection{Shared Data Sources \& Assignment
}
234 Shared data sources must be acquired from the state and constructing one
235 involves multiple steps. First, a fresh identifier is grabbed from the state.
236 Then a
\CI{BCShare
} record is created with that identifier. A
\CI{BCSdsFetch
}
237 instruction is written and the body is generated to finally add the
\gls{SDS
}
238 to the actual state with the value obtained from the function. The exact
239 implementation is shown in Listing~
\ref{lst:shareview
}.
241 \begin{lstlisting
}[label=
{lst:shareview
},
%
242 caption=
{Bytecode view for
\texttt{arith
}}]
243 freshshare = get >>=
\st=:
{freshs
}->put
{st & freshs=freshs+
1} >>| pure freshs
245 instance sds ByteCode where
246 sds f =
{main = BC (freshshare
247 >>=
\sdsi->pure
{BCShare|sdsi=sdsi,sdsval=BCValue
0}
248 >>=
\sds->pure (f (tell`
[BCSdsFetch sds
]))
249 >>= \(v In bdy)->modify (addSDS sds v)
250 >>| unBC (unMain bdy))
252 instance sdspub ByteCode where
253 pub (BC x) = BC (censor (\
[BCSdsFetch s
]->
[BCSdsPublish s
]) x)
255 addSDS sds v s =
{s & sdss=
[{sds & sdsval=BCValue v
}:s.sdss
]}
258 All assignable types compile to a
\gls{RWST
} that writes one fetch instruction.
259 For example, using a
\gls{SDS
} always results in an expression of the form
260 \CI{sds
\x=
4 In ...
}. The actual
\CI{x
} is the
\gls{RWST
} that always writes
261 one
\CI{BCSdsFetch
} instruction with the correct
\gls{SDS
} embedded. Assigning
262 to an analog pin will result in the
\gls{RWST
} containing the
\CI{BCAnalogRead
}
263 instruction. When the assignable is not a read from but assigned to, the
264 instruction will be rewritten as a store instruction. Resulting in an
265 \CI{BCSdsStore
} or
\CI{BCAnalogWrite
} instruction respectively. The
266 implementation for this is given in Listing~
\ref{lst:assignmentview
}.
268 \begin{lstlisting
}[label=
{lst:assignmentview
},
%
269 caption=
{Bytecode view implementation for assignment.
}]
270 instance assign ByteCode where
271 (=.) (BC v) (BC e) = BC (e >>| censor makeStore v)
273 makeStore
[BCSdsFetch i
] =
[BCSdsStore i
]
274 makeStore
[BCDigitalRead i
] =
[BCDigitalWrite i
]
275 makeStore
[...
] =
[...
]
278 \subsection{Actual Compilation
}
279 All the previous functions are tied together with the
\CI{toMessages
} function.
280 This function compiles the bytecode and transforms the
\gls{Task
} in a message.
281 The
\glspl{SDS
} that were not already sent to the device are also added as
282 messages to be sent to the device. This functionality is listed in
283 Listing~
\ref{lst:compilation
}. The compilation process consists of two steps.
284 First, the
\gls{RWST
} is executed. Then, the
\emph{Jump
} statements that
285 jump to labels are transformed to jump to program memory addresses. The
286 translation of labels is possible in one sweep because no labels are reused.
287 Reusing labels would not give a speed improvement since the labels are removed
290 \begin{lstlisting
}[label=
{lst:compilation
},
%
291 caption=
{Actual compilation.
}]
292 bclength :: BC -> Int
293 bclength (BCPush s) =
1 + size (toByteCode s)
295 bclength x =
1 + consNum
{|*|
} x
297 computeGotos ::
[BC
] Int -> (
[BC
], Map Int Int)
298 computeGotos
[] _ = (
[], newMap)
299 computeGotos
[BCLab l:xs
] i = appSnd ('DM'.put l i) (computeGotos xs i)
300 computeGotos
[x:xs
] i = appFst (
\bc->
[x:bc
]) (computeGotos xs (i + bclength x))
302 toRealByteCode :: (ByteCode a b) BCState -> (String, BCState)
304 # (s, bc) = runBC x s
305 # (bc, gtmap) = computeGotos bc
1
306 = (concat (map (toString o toByteVal) (map (implGotos gtmap) bc)), s)
308 toMessages :: MTaskInterval (Main (ByteCode a b)) BCState -> (
[MTaskMSGSend
], BCState)
309 toMessages interval x oldstate
310 # (bc, newstate) = toRealByteCode (unMain x) oldstate
311 # newsdss = difference newstate.sdss oldstate.sdss
312 = (
[MTSds sdsi e\\
{sdsi,sdsval=e
}<-newsdss
] ++
[MTTask interval bc
], newstate)
316 The heating example given previously in Listing~
\ref{lst:exmtask
} would be
317 compiled to the following code. The left column indicates the
318 position in the program memory.
320 \begin{lstlisting
}[caption=
{Thermostat bytecode
},language=c
]
321 1-
2 : BCAnalogRead (Analog A0)
322 3-
6 : BCPush (Int
50)
324 8-
9 : BCJmpF
17 //Jump to else
325 10-
12: BCPush (Bool
1)
326 13-
14: BCDigitalWrite (Digital D0)
327 15-
16: BCJmp
21 //Jump to end of if
328 17-
19: BCPush (Bool
0) //Else label
329 20 : BCDigitalWrite (Digital D0)
331 \todo{More elaborate example
}