in the aforementioned \gls{mTask}-\gls{EDSL}. Some functionality of the
original \gls{mTask}-\gls{EDSL} will not be used in this system. 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
+the nature of class based shallow embedding this obstacle is 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.
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 at predetermined intervals.
+ \CI{OnInterval} has the number of milliseconds to wait in between
+ executions as a parameter. \Glspl{Task} running with this scheduling
+ method are executed at predetermined intervals.
\item\CI{OnInterrupt}
The last scheduling method is running \glspl{Task} on a specific
\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 \gls{SDS}
-is updated, a broadcast to everyone in the system watching is made to notify
-them of the update. \glspl{SDS} can update very often and the
+compared to 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.
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:
+functionality. Programmers can choose to implement it for existing views 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
memory of the device. To compile the \gls{EDSL} code to bytecode, a view 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}) 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 \glspl{SDS} used.
+that writes bytecode instructions (\CI{BC}, Subsection~\label{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
+register of \glspl{SDS} that are 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
instance serial ByteCode
\end{lstlisting}
-\subsection{Instruction Set}
+\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 expressively while keeping all
-instruction one byte.
+kept large, but under $255$, to get the highest expressivity 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.
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 us access to
+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
-Listing~\ref{lst:helpers}. The \CI{op} and \CI{op2} function is 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.
+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.
\begin{lstlisting}[label={lst:helpers},caption={Some helper functions}]
op2 :: (ByteCode a p1) (ByteCode a p2) BC -> ByteCode b Expr
\end{lstlisting}
\subsection{Arithmetics \& Peripherals}
-Almost all of the code from the simple classes use exclusively helper
+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.
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 and then they are placed in the correct order in the
+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}}]
+ caption={Bytecode view for \texttt{arith} class}]
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
noOp = tell` [BCNop]
\end{lstlisting}
-The semantics for the \glspl{mTask} bytecode view are different than the
+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
\end{lstlisting}
\subsection{Shared Data Sources \& Assignment}
-Shared data sources must be acquired from the state and constructing one
-involves multiple steps. First, a fresh identifier is grabbed from the state.
-Then a \CI{BCShare} record is created with that identifier. A \CI{BCSdsFetch}
+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
+\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}.
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 correct \gls{SDS} embedded. Assigning
-to an analog pin will result in the \gls{RWST} containing the \CI{BCAnalogRead}
-instruction. When the assignable is not a read from but assigned to, the
-instruction will be rewritten as a store instruction. Resulting in an
-\CI{BCSdsStore} or \CI{BCAnalogWrite} instruction respectively. The
-implementation for this is given in Listing~\ref{lst:assignmentview}.
+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}
+instruction respectively. The implementation for this is given in
+Listing~\ref{lst:assignmentview}.
\begin{lstlisting}[label={lst:assignmentview},%
caption={Bytecode view implementation for assignment.}]
repositories / msc-thesis1617.git / commitdiff