\begin{figure}
\centering
- \includegraphics[width=.75\linewidth]{todo0g}
+ \includegraphics[width=\linewidth]{todo0g}
\caption{The \gls{UI} for the shared to-do list in \gls{ITASK}.}%
\label{fig:todo}
\end{figure}
-\subsection{\texorpdfstring{\Gls{MTASK}}{MTask}}
-The behaviour of \gls{IOT} edge devices can often be succinctly described by \gls{TOP} programs.
+\subsection{The \texorpdfstring{\gls{MTASK}}{mTask} system}
+The work for \gls{IOT} edge devices can often be succinctly described by \gls{TOP} programs.
Software on microcontrollers is usually composed of smaller basic tasks, are interactive, and share data with other components or the server.
-\Gls{ITASK} seems an obvious candidate at first glance for extending \gls{TOP} to \gls{IOT} edge device.
-An \gls{ITASK} application contains many features that are not needed on \emph{edge devices} such as first-order tasks, support for a distributed architecture, or a multi-user web server.
-Furthermore, \gls{IOT} edge devices are in general not powerful enough to run or interpret \gls{CLEAN}\slash\gls{ABC} code, they just lack the processor speed and the memory.
-To bridge this gap, \gls{MTASK} was developed, a domain-specific \gls{TOP} system for \gls{IOT} edge devices that is integrated in \gls{ITASK} \citep{koopman_task-based_2018}.
-\Gls{ITASK} abstracts away from details such as user interfaces, data storage, client-side platforms, and persistent workflows.
+The \gls{ITASK} system seems an obvious candidate at first glance for bringing \gls{TOP} to \gls{IOT} edge devices.
+An \gls{ITASK} application contains many features that are not needed on \emph{edge devices} such as higher-order tasks, support for a distributed architecture, or a multi-user web server.
+Furthermore, \gls{IOT} edge devices are in general not powerful enough to run or interpret \gls{CLEAN}\slash\gls{ABC} code, they just lack the processor speed and memory.
+To bridge this gap, \gls{MTASK} is developed, a domain-specific \gls{TOP} system for \gls{IOT} edge devices that is integrated in \gls{ITASK} \citep{koopman_task-based_2018}.
+The \gls{ITASK} language abstracts away from details such as user interfaces, data storage, client-side platforms, and persistent workflows.
On the other hand, \gls{MTASK} offers abstractions for edge layer-specific details such as the heterogeneity of architectures, platforms, and frameworks; peripheral access; (multi) task scheduling; and lowering energy consumption.
-\Gls{MTASK} is seamlessly integrated with \gls{ITASK}: \gls{MTASK} tasks are integrated in such a way that they function as \gls{ITASK} tasks, and \glspl{SDS} on the device can tether an \gls{ITASK} \gls{SDS}.
+The \gls{MTASK} system is seamlessly integrated with \gls{ITASK}.
+Tasks in \gls{MTASK} are integrated in such a way that they function as regular \gls{ITASK} tasks.
+Furthermore, \glspl{SDS} on the device can tether \gls{ITASK} \glspl{SDS}.
Using \gls{MTASK}, the programmer can define all layers of an \gls{IOT} system as a single declarative specification.
The \gls{MTASK} language is written in \gls{CLEAN} as a multi-view \gls{EDSL} and hence there are multiple interpretations possible.
The byte code compiler is the most relevant for this thesis.
From an \gls{MTASK} task constructed at run time, a compact binary representation of the work that needs to be done is compiled.
This byte code is then sent to a device that running the \gls{MTASK} \gls{RTS}.
-This feather-light domain-specific \gls{OS} is written in portable \gls{C} with a minimal device specific interface and functions as a \gls{TOP} engine.
+This feather-light domain-specific \gls{OS} is written in portable \gls{C} with a minimal device specific interface and it executes the tasks using interpretation and rewriting.
-\Cref{lst:intro_blink,fig:intro_blink} shows the \gls{ITASK} part of the code and a screenshot of an interactive \imtask{} application for blinking \pgls{LED} on the microcontroller every dynamically changeable interval.
-Using \cleaninline{enterInformation}, the connection specification of the \gls{TCP} device is queried (\cref{lst:intro_enterDevice}).
+To illustrate \imtask{}, an example application is shown.
+The application is an interactive application for blinking \pgls{LED} on the microcontroller at a certain frequency that can be set and updated at run time.
+\Cref{lst:intro_blink,fig:intro_blink} show the \gls{ITASK} part of the code and a screenshot.
+Using \cleaninline{enterInformation}, the connection specification of the \gls{TCP} device is queried through a web editor (\cref{lst:intro_enterDevice,fig:intro_blink_dev}).
\Cref{lst:intro_withshared} defines \pgls{SDS} to communicate the blinking interval between the server and the edge device.
-The \gls{MTASK} is connected using \cleaninline{withDevice} at \cref{lst:intro_withdevice}.
-Once connected, the \cleaninline{intBlink} task is sent to the device (\cref{lst:intro_liftmtask}) and, in parallel, a web editor is shown that updates the value of the interval \gls{SDS} (\cref{lst:intro_editor}).
-To allow ending the task, the \gls{ITASK} task ends with a sequential operation that returns a constant value when the button is pressed, making the task stable.
+The \gls{MTASK} device is connected using \cleaninline{withDevice} at \cref{lst:intro_withdevice}.
+Once connected, the \cleaninline{intBlink} task is sent to the device (\cref{lst:intro_liftmtask}) and, in parallel, a web editor is shown that updates the value of the interval \gls{SDS} (\cref{lst:intro_editor,fig:intro_blink_int}).
+To allow terminating of the task, the \gls{ITASK} task ends with a sequential operation that returns a constant value when the button is pressed, making the task stable.
\cleaninputlisting[firstline=10,lastline=18,numbers=left,caption={The \gls{ITASK} code for the interactive blinking application.},label={lst:intro_blink}]{lst/blink.icl}
\begin{subfigure}{.5\textwidth}
\centering
\includegraphics[width=.9\linewidth]{blink1g}
- \caption{Device selection.}
+ \caption{Device selection.}\label{fig:intro_blink_dev}
\end{subfigure}%
\begin{subfigure}{.5\textwidth}
\centering
\includegraphics[width=.9\linewidth]{blink2g}
- \caption{Changing the interval.}
+ \caption{Changing the interval.}\label{fig:intro_blink_int}
\end{subfigure}
\caption{The \gls{UI} for the interactive blink application in \gls{MTASK}.}%
\label{fig:intro_blink}
It has its own tasks, \glspl{SDS}, and \gls{UOD}.
This task first defines \gls{GPIO} pin 13 to be of the output type (\cref{lst:intro:declarePin}), followed by lifting the \gls{ITASK} \gls{SDS} to an \gls{MTASK} \gls{SDS} (\cref{lst:intro:liftsds}).
The main expression of the program calls the \cleaninline{blink} function with an initial state.
-This function on \crefrange{lst:intro:blink_fro}{lst:intro:blink_to} first reads the interval \gls{SDS}, waits the specified delay, writes the state to the \gls{GPIO} pin and calls itself recursively using the inverse of the state.
+This function on \crefrange{lst:intro:blink_fro}{lst:intro:blink_to} first reads the interval \gls{SDS}, waits the specified delay, writes the state to the \gls{GPIO} pin, and calls itself recursively using the inverse of the state in order to run continuously.
\begin{lstClean}[numbers=left,belowskip=0pt]
intBlink :: (Shared sds Int) -> Main (MTask v Int) | mtask v & ...\end{lstClean}
-\cleaninputlisting[aboveskip=0pt,firstnumber=3,firstline=22,numbers=left,caption={The \gls{MTASK} code for the interactive blinking application.},label={lst:intro_blink_mtask}]{lst/blink.icl}
+\cleaninputlisting[aboveskip=0pt,firstnumber=4,firstline=23,numbers=left,caption={The \gls{MTASK} code for the interactive blinking application.},label={lst:intro_blink_mtask}]{lst/blink.icl}
\subsection{Other \texorpdfstring{\glsxtrshort{TOP}}{TOP} languages}
-While \gls{ITASK} conceived \gls{TOP}, it is not the only \gls{TOP} system.
+While \gls{ITASK} conceived \gls{TOP}, it is not the only \gls{TOP} system anymore.
Some \gls{TOP} languages were created to fill a gap encountered in practise.
Toppyt \citep{lijnse_toppyt_2022} is a general purpose \gls{TOP} language written in \gls{PYTHON} used to host frameworks for modelling \emph{Command\&Control} systems, and hTask \citep{lubbers_htask_2022}, a vessel for experimenting with asynchronous \glspl{SDS}.
Furthermore, some \gls{TOP} systems arose from Master's and Bachelor's thesis projects.
This section provides a thorough overview of the relation between the scientific publications and the contents of this thesis.
\subsection{\Fullref{prt:dsl}}
-The \gls{MTASK} system is a heterogeneous \gls{EDSL} and during the development of it, several novel basal techniques for embedding \glspl{DSL} in \gls{FP} languages have been found.
+The \gls{MTASK} system is an \gls{EDSL} and during the development of it, several novel basal techniques for embedding \glspl{DSL} in \gls{FP} languages have been found.
This paper-based episode contains the following papers:
\begin{enumerate}
\item \emph{Deep Embedding with Class} \citep{lubbers_deep_2022} is the basis for \cref{chp:classy_deep_embedding}.
It shows a novel deep embedding technique for \glspl{DSL} where the resulting language is extendible both in constructs and in interpretation just using type classes and existential data types.
The related work section is updated with the research found after publication.
\Cref{sec:classy_reprise} was added after publication and contains a (yet) unpublished extension of the embedding technique for reducing the required boilerplate at the cost of requiring some advanced type system extensions.
- \item \emph{First-Class Data Types in Shallow Embedded Domain-Specific Languages} \citep{lubbers_first-class_2022}\label{enum:first-class} is the basis for \cref{chp:first-class_datatypes}.
+ \item \emph{First-\kern-1ptClass Data Types in Shallow Embedded Domain-Specific Languages} \citep{lubbers_first-class_2022}\label{enum:first-class} is the basis for \cref{chp:first-class_datatypes}.
It shows how to inherit data types from the host language in \glspl{EDSL} using metaprogramming by providing a proof-of-concept implementation using \gls{HASKELL}'s metaprogramming system: \glsxtrlong{TH}.
The paper also serves as a gentle introduction to, and contains a thorough literature study on \glsxtrlong{TH}.
\end{enumerate}
\paragraph{Other publications on \texorpdfstring{\glspl{EDSL}}{eDSLs}:}
-Furthermore, I co-authored another paper that is not part of the \gls{MTASK} system yet and hence not part of the dissertation.
+Furthermore, I co-authored a paper that is not part of the \gls{MTASK} system yet and hence not part of the dissertation.
\begin{enumerate}[resume]
- \item \emph{Strongly-Typed Multi-View Stack-Based Computations} \citep{koopman_strongly-typed_2022}\label{enum:stack-based} shows how to create type-safe \glspl{EDSL} representing stack-based computations.
+ \item \emph{Strongly-Typed Multi-\kern-2.5ptView Stack-\kern-1.25ptBased Computations} \citep{koopman_strongly-typed_2022}\label{enum:stack-based} shows how to create type-safe \glspl{EDSL} representing stack-based computations.
Instead of encoding the arguments to a function as arguments in the host language, stack-based approaches use a run time stack that contains the arguments.
By encoding the required contents of the stack in the types, such systems can be made type safe.
\end{enumerate}
\paragraph{Contribution:}
The papers of which I am first author are solely written by me, there were weekly meetings with co-authors in which we discussed and refined the ideas.
-\subsection{\Fullref{prt:top}}
+\subsection{\crtCref{prt:top}: \hspace{8.28992pt}\nameref{prt:top}}
This episode is a monograph that shows the design, properties, implementation and usage of the \gls{MTASK} system and \gls{TOP} for the \gls{IOT}.
It is compiled from the following publications:
\begin{enumerate}[resume]
- \item \emph{A Task-Based \glsxtrshort{DSL} for Microcomputers} \citep{koopman_task-based_2018}
+ \item \emph{A Task-\kern-1.25ptBased \glsxtrshort{DSL} for Microcomputers} \citep{koopman_task-based_2018}
is the initial \gls{TOP}\slash{}\gls{MTASK} paper.
It provides an overview of the initial \gls{TOP} \gls{MTASK} language and shows first versions of some interpretations.
\item \emph{Task Oriented Programming for the Internet of Things} \citep{lubbers_task_2018}\footnotetext{This work is an extension of my Master's thesis \citep{lubbers_task_2017}.}
is a short paper on the multitasking capabilities of \gls{MTASK} comparing it to traditional multitasking methods for \gls{ARDUINO}.
% \paragraph{Contribution}
% The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer.
- \item \emph{Simulation of a Task-Based Embedded Domain Specific Language for the Internet of Things} \citep{koopman_simulation_2018}\footnotemark[\value{footnote}]
+ \item \emph{Simulation of a Task-\kern-1.25ptBased Embedded Domain Specific Language for the Internet of Things} \citep{koopman_simulation_2018}\footnotemark[\value{footnote}]
are the revised lecture notes for a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}\slash{}\gls{3COWS} winter school in Ko\v{s}ice, Slovakia, January 22--26, 2018.
% \paragraph{Contribution}
% Pieter Koopman wrote and taught it, I helped with the software and research.
I extended the language, developed the byte code interpreter, the integration with \gls{ITASK}, and the \gls{RTS}.
The paper of which I am first author are solely written by me, there were weekly meetings with the co-authors in which we discussed and refined the ideas.
-\subsection{\nameref{prt:tvt}}
+\subsection{\Fullref{prt:tvt}}
\Cref{prt:tvt} is based on a journal paper that quantitatively and qualitatively compares traditional \gls{IOT} architectures with \gls{IOT} systems using \gls{TOP} and contains a single chapter.
This chapter is based on the conference paper and a journal paper extending it:
\begin{enumerate}[resume]
\paragraph{Contribution:}
Writing the paper was performed by all authors.
I created the server application, the \cimtask{} implementation (\glsxtrshort{CWS}), and the \citask{} implementation (\glsxtrshort{CRS});
-Adrian Ramsingh created the \gls{MICROPYTHON} implementation (\glsxtrshort{PWS}); the original \gls{PYTHON} implementation (\glsxtrshort{PRS}), and the server application were created by \citet{hentschel_supersensors:_2016}.
+Adrian Ramsingh created the \gls{MICROPYTHON} implementation (\glsxtrshort{PWS}); the original \gls{PYTHON} implementation (\glsxtrshort{PRS}) and the server application were created by \citet{hentschel_supersensors:_2016}.
\input{subfilepostamble}
\end{document}
\subsection{Execution}
The second phase consists of performing one execution step for all tasks that wish for it.
Tasks are ordered in a priority queue ordered by the time a task needs to be executed, the \gls{RTS} selects all tasks that can be scheduled, see \cref{sec:scheduling} for more details.
-A task is stored below the stack and its complete state is a \gls{CLEAN} record contain most importantly the task id, a pointer to the task tree in the heap (null if not initialised yet), the current task value, the configuration of \glspl{SDS}, the configuration of peripherals, the byte code and some scheduling information.
+Execution of a task is always an interplay between the interpreter and the \emph{rewriter}.
If a task is not initialized yet, i.e.\ the pointer to the current task tree is still null, the byte code of the main function is interpreted.
The main expression always produces a task tree.
+Execution of a task consists of continuously rewriting the task until its value is stable.
+Rewriting is a destructive process, i.e.\ the rewriting is done in place.
The rewriting engine uses the interpreter when needed, e.g.\ to calculate the step continuations.
The rewriter and the interpreter use the same stack to store intermediate values.
Rewriting steps are small so that interleaving results in seemingly parallel execution.
\caption{Memory layout}\label{fig:memory_layout}
\end{figure}
+A task is stored below the stack and its complete state is a \gls{CLEAN} record contain most importantly the task id, a pointer to the task tree in the heap (null if not initialised yet), the current task value, the configuration of \glspl{SDS}, the configuration of peripherals, the byte code and some scheduling information.
+
In memory, task data grows from the bottom up and the interpreter stack is located directly on top of it growing in the same direction.
As a consequence, the stack moves when a new task is received.
This never happens within execution because communication is always processed before execution.
-Values in the interpreter are always stored on the stack, even tuples.
+Values in the interpreter are always stored on the stack.
+Compound data types are stored unboxed and flattened.
Task trees grow from the top down as in a heap.
This approach allows for flexible ratios, i.e.\ many tasks and small trees or few tasks and big trees.
For task trees---stored in the heap---the \gls{RTS} already marks tasks and task trees as trash during rewriting so the heap can be compacted in a single pass.
This is possible because there is no sharing or cycles in task trees and nodes contain pointers pointers to their parent.
-\todo{plaa\-tje van me\-mo\-ry hier}
+\todo{plaa\-tje van me\-mo\-ry hier uitbreiden}
\section{Compiler}
\subsection{Instruction set}
The instruction set is a fairly standard stack machine instruction set extended with special \gls{TOP} instructions.
+
\Cref{lst:instruction_type} shows the \gls{CLEAN} type representing the instruction set of which \cref{tbl:instr_task} gives detailed semantics.
Type synonyms are used to provide insight on the arguments of the instructions.
One notable instruction is the \cleaninline{MkTask} instruction, it allocates and initialises a task tree node and pushes a pointer to it on the stack.
Furthermore, a \ccpp{} parser and printer is generated for use on the \gls{MTASK} device.
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}
+%\todo[inline]{conclusion}
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / commitdiff