From: Mart Lubbers Date: Mon, 26 Jun 2017 11:44:16 +0000 (+0200) Subject: Camil's comments: chapter 5 X-Git-Tag: hand-in~43 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=c7dbfdf743febd94770d3ce10d7d532a6bdd94cc;p=msc-thesis1617.git Camil's comments: chapter 5 --- diff --git a/methods.mtask.tex b/methods.mtask.tex index d8d9fdf..1f5c4ec 100644 --- a/methods.mtask.tex +++ b/methods.mtask.tex @@ -70,7 +70,9 @@ in Listing~\ref{lst:control}. The first class of \emph{If} statements describes the regular \emph{if} statement. The expressions given can have any role. The functional dependency on \CI{s} determines the return type of the statement. The listing includes examples of implementations that illustrate this -dependency. +dependency. A special \emph{If} statement --- only used for statements --- is +also added under the name \CI{IF}, of which the \CI{?} is a conditional +statement to execute. The sequence operator is straightforward and its only function is to tie two expressions together. The left expression is executed first, followed by @@ -81,6 +83,10 @@ the right expression. class If v q r ~s where If :: (v Bool p) (v t q) (v t r) -> v t s | ... +class IF v where + IF :: (v Bool p) (v t q) (v s r) -> v () Stmt | ... + (?) infix 1 :: (v Bool p) (v t q) -> v () Stmt | ... + instance If Code Stmt Stmt Stmt instance If Code e Stmt Stmt instance If Code Stmt e Stmt diff --git a/results.mtask.tex b/results.mtask.tex index 1872019..6496b73 100644 --- a/results.mtask.tex +++ b/results.mtask.tex @@ -31,24 +31,25 @@ reflected in the \CI{MTTask} message type. \item\CI{OnInterrupt} The last scheduling method is running \glspl{Task} on a specific - interrupt. None of the current client implementations support this. - However, registering interrupts on, for example the \gls{Arduino} is - very straightforward. 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. + 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} \Glspl{SDS} on a client are available on the server as well as regular -\gls{SDS}. 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 different on an \gls{mTask} device -compared to the \gls{iTasks} system. In an \gls{iTasks} system, when the +\glspl{SDS}. However, the same freedom 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 serializable and 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. This results in a lot of -expensive unneeded bandwidth usage. Therefore a device must publish the -\gls{SDS} explicitly to save bandwidth. +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} @@ -117,8 +118,8 @@ instance serial ByteCode \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 the highest expressivity while keeping all -instruction within one byte. +kept large, but under $255$, to get as much expressieve power as possible 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. @@ -152,20 +153,21 @@ and avoid label lookups at runtime. | BCReturn \end{lstlisting} -All single byte instructions are converted automatically using the generic -function \CI{consIndex} which returns the index of the constructor. The index -of the constructor is the byte value for all instructions. The last step of the +All single byte instructions are converted automatically using a generic +function which returns the index of the constructor. The index of the +constructor is the byte value for all instructions. Added to this single byte +value are the encoded parameters of the instruction. The last step of the compilation is transforming the list of bytecode instructions to actual bytes. \subsection{Helper functions} -The \CI{ByteCode} type is just a boxed \gls{RWST} and that gives access to -the whole range of \gls{RWST} functions. However, to apply a function the type -must be unboxed. After application the type must be boxed again. To achieve -this, several helper functions have been created. They are listed in +Since the \CI{ByteCode} type is just a boxed \gls{RWST}, access to the whole +range of \gls{RWST} functions is available. However, to use this, the type must +be unboxed. After application the type must be boxed again. To achieve this, +several helper functions have been created. They are given in Listing~\ref{lst:helpers}. The \CI{op} and \CI{op2} functions is hand-crafted to make operators that pop one or two values off the stack respectively. The -\CI{tell`} is a wrapper around the \gls{RWST} function \CI{tell} that appends -the argument to the \emph{Writer} value. +\CI{tell`} function is a wrapper around the \gls{RWST} function \CI{tell} that +appends the argument to the \emph{Writer} value. \begin{lstlisting}[label={lst:helpers},caption={Some helper functions}] op2 :: (ByteCode a p1) (ByteCode a p2) BC -> ByteCode b Expr @@ -183,9 +185,9 @@ unBC (BC x) = x \subsection{Arithmetics \& Peripherals} Almost all of the code from the simple classes exclusively use helper -functions. Listing~\ref{lst:arithview} shows some implementations. The classes -\CI{boolExpr} and the classes for the peripherals are implemented using the -same strategy. +functions. Listing~\ref{lst:arithview} shows some implementations. The +\CI{boolExpr} class and the classes for the peripherals are implemented using +the same strategy. \begin{lstlisting}[label={lst:arithview},caption={% Bytecode view implementation for arithmetic and peripheral classes}] @@ -201,13 +203,12 @@ instance userLed ByteCode where \subsection{Control Flow} Implementing the sequence operator is very straightforward in the bytecode -view. The function just sequences the two \glspl{RWST}. The \emph{If} statement -requires some detailed explanation since labels come into play. The -implementation speaks for itself in Listing~\ref{lst:controlflow}. First, all -the labels are gathered after which they are placed in the correct order in the -bytecode sequence. It can happen that multiple labels appear consecutively in -the code. This is not a problem since the labels are resolved to real addresses -later on anyway. +view. The function just sequences the two \glspl{RWST}. The +implementation for the \emph{If} statement speaks for itself in +Listing~\ref{lst:controlflow}. First, all the labels are gathered after which +they are placed in the correct order in the bytecode sequence. It can happen +that multiple labels appear consecutively in the code. This is not a problem +since the labels are resolved to real addresses later on anyway. \begin{lstlisting}[label={lst:controlflow},% caption={Bytecode view for \texttt{arith} class}] @@ -232,12 +233,12 @@ instance noOp ByteCode where \end{lstlisting} The semantics for the \glspl{mTask} bytecode view are different from the -semantics for the \gls{C} view. \glspl{Task} in the \gls{C} view can start new -\gls{Task} or themselves to continue, while in the bytecode view, \gls{Task} -run idefinitly, one-shot or on interrupt. To allow interval and interrupt -\glspl{Task} to terminate, a return instruction is added. This class was not -available in the original system and is thus added. It just writes a single -instruction so that the interpreter knows to stop execution. +semantics of the \gls{C} view. \glspl{Task} in the \gls{C} view can start new +\glspl{Task} or even start themselves to continue, while in the bytecode view, +\glspl{Task} run indefinitly, one-shot or on interrupt. To allow interval and +interrupt \glspl{Task} to terminate, a return instruction is added. This class +was not available in the original system and is thus added. It just writes a +single instruction so that the interpreter knows to stop execution. Listing~\ref{lst:return} shows the classes and implementation for the return expression. @@ -275,14 +276,14 @@ 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} that writes one fetch instruction. -For example, using a \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 an \CI{BCSdsStore} or \CI{BCAnalogWrite} +All assignable types compile to a \gls{RWST} which writes the specific fetch +instruction(s). For example, using a \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}. @@ -298,15 +299,15 @@ makeStore [...] = [...] \subsection{Actual Compilation} All the previous functions are tied together with the \CI{toMessages} function. -This function compiles the bytecode and transforms the \gls{Task} in a message. +This function compiles the bytecode and transforms the \gls{Task} to a message. The \glspl{SDS} that were not already sent to the device are also added as -messages to be sent to the device. This functionality is listed in +messages to be sent to the device. This functionality is shown in Listing~\ref{lst:compilation}. The compilation process consists of two steps. First, the \gls{RWST} is executed. Then, the \emph{Jump} statements that jump to labels are transformed to jump to program memory addresses. The -translation of labels is possible in one sweep because no labels are reused. +translation of labels is possible in one sweep because fresh labels are reused. Reusing labels would not give a speed improvement since the labels are removed -anyway in the end. +in the end. \begin{lstlisting}[label={lst:compilation},% caption={Actual compilation.}] @@ -334,7 +335,7 @@ toMessages interval x oldstate \end{lstlisting} \section{Examples} -The heating example given previously in Listing~\ref{lst:exmtask} would be +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.