The \gls{mTask}-\glspl{Task} 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 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
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
variables are added. This means that the programmer has to unbox the
\CI{ByteCode} object to be able to make use of the \gls{RWST} functionality
such as return values. Tailor made access functions are used to achieve this
with ease. The fresh variable stream in a compiler using a \gls{RWST} is often
put into the \emph{Reader} part of the monad. However, not all code is compiled
immediately and later on the fresh variable stream cannot contain variables
that were used before. Therefore this information is put in the state which is
kept between compilations.

Not all types are suitable for usage in bytecode compiled programs. Every value
used in the bytecode view must fit in the \CI{BCValue} type which restricts
the content. Most notably, the type must be bytecode encodable. A \CI{BCValue}
must be encodable and decodable without losing type or value information. At
the moment a simple encoding scheme is used that uses single byte prefixes to
detect the type of the value. The devices know these prefixes and can apply the
same detection if necessary.

\begin{lstlisting}[label={lst:bcview},caption={Bytecode view}]
:: ByteCode a p = BC (RWS () [BC] BCState ())
:: BCValue = E.e: BCValue e & mTaskType, TC e
:: BCShare =
	{ sdsi :: Int
	, sdsval :: BCValue
	}
:: BCState = 
	{ freshl :: Int
	, freshs :: Int
	, sdss :: [BCShare]
	}

class toByteCode a :: a -> String
class fromByteCode a :: String -> a
class mTaskType a | toByteCode, fromByteCode, iTask, TC a

instance toByteCode Int, ... , UserLED, BCValue
instance fromByteCode Int, ... , UserLED, BCValue

instance arith ByteCode
...
instance serial ByteCode
\end{lstlisting}

\subsection{Instruction Set}\label{sec:instruction}
The instruction set is given in Listing~\ref{bc:instr}. The instruction set is
kept large, but the number of instructions stays under $255$ to get as much
expressive power 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.
However, this is not a real instruction and the labels are resolved to actual
program memory addresses in the final step of compilation to save instructions
and avoid label lookups at runtime.

\begin{lstlisting}[label={bc:instr},%
	caption={Bytecode instruction set}]
:: BC = BCNop
	| BCLab Int          | BCPush BCValue     | BCPop
	//SDS functions
	| BCSdsStore BCShare | BCSdsFetch BCShare | BCSdsPublish BCShare
	//Unary ops
	| BCNot
	//Binary Int ops
	| BCAdd              | BCSub              | BCMul
	| BCDiv
	//Binary Bool ops
	| BCAnd              | BCOr
	//Binary ops
	| BCEq               | BCNeq              | BCLes             | BCGre
	| BCLeq              | BCGeq
	//Conditionals and jumping
	| BCJmp Int          | BCJmpT Int         | BCJmpF Int
	//UserLED
	| BCLedOn            | BCLedOff
	//Pins
	| BCAnalogRead Pin   | BCAnalogWrite Pin  | BCDigitalRead Pin | BCDigitalWrite Pin
	//Return
	| BCReturn
\end{lstlisting}

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}
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`} 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
op2 (BC x) (BC y) bc = BC (x >>| y >>| tell [bc])

op :: (ByteCode a p) BC -> ByteCode b c
op (BC x) bc = BC (x >>| tell [bc])

tell` :: [BC] -> (ByteCode a p)
tell` x = BC (tell x)

unBC :: (ByteCode a p) -> RWS () [BC] BCState ()
unBC (BC x) = x
\end{lstlisting}

\subsection{Arithmetics \& Peripherals}
Almost all of the code from the simple classes exclusively use helper
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}]
instance arith ByteCode where
	lit x = tell` [BCPush (BCValue x)]
	(+.) x y = op2 x y BCDiv
	...

instance userLed ByteCode where
	ledOn  l = op l BCLedOn
	ledOff l = op l BCLedOff
\end{lstlisting}

\subsection{Control Flow}
Implementing the sequence operator is very straightforward in the bytecode
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}]
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
instance If ByteCode Stmt e Stmt    where If b t e = BCIfStmt b t e
instance If ByteCode x y Stmt       where If b t e = BCIfStmt b t e
instance IF ByteCode where
	IF b t e = BCIfStmt b t e
	(?) b t = BCIfStmt b t (tell` [])
BCIfStmt (BC b) (BC t) (BC e) = BC (
	freshlabel >>= \else->freshlabel >>= \endif->
	b >>| tell [BCJmpF else] >>|
	t >>| tell [BCJmp endif, BCLab else] >>|
	e >>| tell [BCLab endif]
	)

instance noOp ByteCode where
	noOp = tell` [BCNop]
\end{lstlisting}

The semantics for the \gls{mTask}-\glspl{Task} bytecode view are different from
the 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 indefinitely, 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.

\begin{lstlisting}[label={lst:return},%
	caption={Bytecode view for the return instruction}]
class retrn v where
  retrn :: v () Expr

instance retrn ByteCode where
	retrn = tell` [BCReturn]
\end{lstlisting}

\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
\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}.

\begin{lstlisting}[label={lst:shareview},%
	caption={Bytecode view for \texttt{arith}}]
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}
			>>= \sds->pure (f (tell` [BCSdsFetch sds]))
			>>= \(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]}
\end{lstlisting}

All assignable types compile to a \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
\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}.

\begin{lstlisting}[label={lst:assignmentview},%
	caption={Bytecode view implementation for assignment.}]
instance assign ByteCode where
	(=.) (BC v) (BC e) = BC (e >>| censor makeStore v)

makeStore [BCSdsFetch i]    = [BCSdsStore i]
makeStore [BCDigitalRead i] = [BCDigitalWrite i]
makeStore [...]             = [...]
\end{lstlisting}

\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} 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 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 fresh labels are reused.
Reusing labels would not give a speed improvement since the labels are removed
in the end.

\begin{lstlisting}[label={lst:compilation},%
	caption={Actual compilation.}]
bclength :: BC -> Int
bclength (BCPush s) = 1 + size (toByteCode s)
bclength ... = ...
bclength x = 1 + consNum{|*|} x

computeGotos :: [BC] Int -> ([BC], Map Int Int)
computeGotos [] _ = ([], newMap)
computeGotos [BCLab l:xs] i = appSnd ('DM'.put l i) (computeGotos xs i)
computeGotos [x:xs] i = appFst (\bc->[x:bc]) (computeGotos xs (i + bclength x))

toRealByteCode :: (ByteCode a b) BCState -> (String, BCState)
toRealByteCode x s
# (s, bc) = runBC x s
# (bc, gtmap) = computeGotos bc 1
= (concat (map (toString o toByteVal) (map (implGotos gtmap) bc)), s)

toMessages :: MTaskInterval (Main (ByteCode a b)) BCState -> ([MTaskMSGSend], BCState)
toMessages interval x oldstate
# (bc, newstate) = toRealByteCode (unMain x) oldstate
# newsdss = difference newstate.sdss oldstate.sdss 
= ([MTSds sdsi e\\{sdsi,sdsval=e}<-newsdss] ++ [MTTask interval bc], newstate)
\end{lstlisting}
