\chapter{Implementation}%
\label{chp:implementation}
\begin{chapterabstract}
- \noindent This chapter shows the implementation of the \gls{MTASK} system by:
+ This chapter shows the implementation of the \gls{MTASK} system by:
\begin{itemize}
- \item gives details of the implementation of \gls{MTASK}'s \gls{TOP} engine that executes the \gls{MTASK} tasks on the microcontroller;
- \item shows the implementation of the byte code compiler for \gls{MTASK}'s \gls{TOP} language;
- \item explains the machinery used to automatically serialise and deserialise data to-and-fro the device.
+ \item giving details of the implementation of \gls{MTASK}'s \gls{TOP} engine that executes the \gls{MTASK} tasks on the microcontroller;
+ \item showing the implementation of the byte code compiler for \gls{MTASK}'s \gls{TOP} language;
+ \item explaining the machinery used to automatically serialise and deserialise data to-and-fro the device.
\end{itemize}
\end{chapterabstract}
-Microcontrollers usually have flash-based program memory which wears out fairly quick.
-For example, the atmega328p in the \gls{ARDUINO} UNO is rated for 10000 write cycles.
+The \gls{MTASK} language targets resource-constrained edge devices that have little memory, processor speed and communication.
+Furthermore, microcontrollers usually have flash-based program memory which wears out fairly quick.
+For example, the flash memory of the popular atmega328p powering the \gls{ARDUINO} UNO is just rated for 10000 write cycles.
While this sounds like a lot, if new tasks are sent to the device every minute or so, a lifetime of only seven days is guaranteed.
-Hence, for dynamic applications, interpretation on the device is necessary, saving precious write cycles of the program memory.
+Hence, for dynamic applications, storing the program in the \gls{RAM} of the device and interpreting this code is necessary, saving precious write cycles of the program memory.
-In order to provide the device with the tools to interpret the byte code, it is programmed with a \gls{RTS}, a customisable domain-specific \gls{OS} that takes care of the execution of tasks but also low-level mechanisms such as the communication, multi tasking, and memory management.
-Once the device is programmed with the \gls{MTASK} \gls{RTS}, it can continuously receive new tasks without the need for reprogramming.
+In the \gls{MTASK} system, this is done by the \gls{MTASK} \gls{RTS}.
+The \gls{RTS} is a customisable domain-specific \gls{OS} that takes care of the execution of tasks, but also low-level mechanisms such as the communication, multitasking, and memory management.
+Once a device is programmed with the \gls{MTASK} \gls{RTS}, it can continuously receive new tasks without the need for reprogramming.
The \gls{OS} is written in portable \ccpp{} and only contains a small device-specific portion.
+In order to keep the abstraction level high and the hardware requirements low, much of the high-level functionality of the \gls{MTASK} language is implemented not in terms of lower-level constructs from \gls{MTASK} language but in terms of \ccpp{} code.
\section{\texorpdfstring{\Glsxtrlong{RTS}}{Run time system}}
The event loop of the \gls{RTS} is executed repeatedly and consists of three distinct phases.
The interface is deliberately kept simple and consists of a two layer interface: a link interface and a communication interface.
Besides opening, closing and cleaning up, the link interface has only three functions that are shown in \cref{lst:link_interface}.
Consequently, implementing this link interface is very simple but allows for many more advanced link settings such as buffering.
-There are implementations for this interface for serial or Wi-Fi connections using \gls{ARDUINO} and \gls{TCP} connections for Linux.
+There are implementations for this interface for serial or \gls{WIFI} connections using \gls{ARDUINO} and \gls{TCP} connections for Linux.
\begin{lstArduino}[caption={Link interface of the \gls{MTASK} \gls{RTS}.},label={lst:link_interface}]
bool link_input_available(void);
...
\end{lstClean}
-\subsection{Compiler}
+\subsection{Compiler infrastructure}
The bytecode compiler interpretation for the \gls{MTASK} language is implemented as a monad stack containing a writer monad and a state monad.
The writer monad is used to generate code snippets locally without having to store them in the monadic values.
The state monad accumulates the code, and stores the stateful data the compiler requires.
a list of all the used \glspl{SDS}, either local \glspl{SDS} containing the initial value (\cleaninline{Left}) or lifted \glspl{SDS} (see \cref{sec:liftsds}) containing a reference to the associated \gls{ITASK} \gls{SDS};
and finally there is a list of peripherals used.
-\begin{lstClean}[label={lst:compiler_state},caption={\Gls{MTASK}'s byte code compiler type}]
+\begin{lstClean}[label={lst:compiler_state},caption={The type for the \gls{MTASK} byte code compiler}]
:: BCInterpret a :== StateT BCState (WriterT [BCInstr] Identity) a
:: BCState =
{ bcs_infun :: JumpLabel
The technique for generating the \ccpp{} parser and printer is very similar to template metaprogramming and requires a generic programming library or compiler support that includes a lot of metadata in the record and constructor nodes.
\section{Conclusion}
-%\todo[inline]{conclusion}
+Tasks in the \gls{MTASK} system are executed on resource-constrained \gls{IOT} edge devices.
+
+\todo[inline]{conclusion}
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff