X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=mtaskext.bytecode.tex;h=887a6b56964f0d964d9867b4003934b42d0b4274;hb=d66b8c6bae6fde77e7ba53759f862364a9505ace;hp=111be6fd5bfc4f479c2365076c09736efb314cb2;hpb=6548a5ec9ce8e0df67fc4019625ab5238eb1bf71;p=msc-thesis1617.git diff --git a/mtaskext.bytecode.tex b/mtaskext.bytecode.tex index 111be6f..887a6b5 100644 --- a/mtaskext.bytecode.tex +++ b/mtaskext.bytecode.tex @@ -4,7 +4,7 @@ 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 +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. @@ -30,13 +30,14 @@ same detection if necessary. :: ByteCode a p = BC (RWS () [BC] BCState ()) :: BCValue = E.e: BCValue e & mTaskType, TC e :: BCShare = - { sdsi :: Int - , sdsval :: BCValue + { sdsi :: Int + , sdsval :: BCValue + , sdsname :: String } :: BCState = { freshl :: Int , freshs :: Int - , sdss :: [BCShare] + , sdss :: [BCShare] } class toByteCode a :: a -> String @@ -188,11 +189,13 @@ instance retrn ByteCode where \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 +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}. +implementation is shown in Listing~\ref{lst:shareview}. The implementation for +the \CI{namedsds} class is exactly the same other than that it stores the given +name in the \CI{BCShare} structure as well. \begin{lstlisting}[label={lst:shareview},% caption={Bytecode view for \texttt{arith}}] @@ -200,7 +203,7 @@ 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} + >>= \sdsi->pure {BCShare|sdsname="",sdsi=sdsi,sdsval=BCValue 0} >>= \sds->pure (f (tell` [BCSdsFetch sds])) >>= \(v In bdy)->modify (addSDS sds v) >>| unBC (unMain bdy)) @@ -211,11 +214,11 @@ 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} which writes the specific fetch +All assignable types compile to an \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 +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}