From: Mart Lubbers Date: Wed, 1 Feb 2023 14:51:07 +0000 (+0100) Subject: comments comemnts comments X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=2260acc961f4041fc214d093d0225d382396564e;p=phd-thesis.git comments comemnts comments --- diff --git a/appx/bytecode.tex b/appx/bytecode.tex index ce6c4df..12e1c82 100644 --- a/appx/bytecode.tex +++ b/appx/bytecode.tex @@ -2,32 +2,35 @@ \input{subfilepreamble} -\setcounter{chapter}{2} \begin{document} \input{subfileprefix} -\ifSubfilesClassLoaded{\appendix}{} +\ifSubfilesClassLoaded{\appendix\setcounter{chapter}{2}}{} \chapter{Bytecode instruction set}% \label{chp:bytecode_instruction_set}% -This appendix describeds the semantics of the byte code instruction set. -The byte code instructions are of variable length and automatically encoded and decoded using generic programming (see \todo{ref naar c\-co\-de\-gen}). +This appendix describeds the semantics of the byte code instruction set of \gls{MTASK} (see \cref{chp:implementation}). +The byte code instructions are of variable length and automatically encoded and decoded using generic programming (see \cref{sec:ccodegen}). \Cref{tbl:bc_notation} shows the notation convention. +\Cref{tbl:instr_task} shows the semantics of all major byte code instructions, shorthand instructions and auxiliary peripherals have been omitted for brevity but have the analogous semantics as their counterparts. -\begin{table}[ht!] - \caption{Notation for the byte code semantics}% +\begin{table} + \caption{Notation convention for the byte code semantics.}% \label{tbl:bc_notation} \centering \begin{tabular}{lll} \toprule variable & meaning & \textnumero{}bytes\\ \midrule + $fp$ & frame pointer & 2\\ + $sp$ & stack pointer & 2\\ + $pc$ & program counter & 2\\ $l$ & label & 2\\ + \midrule $w_r$ & return width & 1\\ $w_a$ & argument width & 1\\ $i$ & \gls{SDS} or sensor id & 1\\ - $fp$ & frame pointer & 2\\ - $sp$ & stack pointer & 2\\ - $pc$ & program counter & 2\\ + $n$ & number & 1\\ + $d$ & depth & 1\\ \bottomrule \end{tabular} \end{table} @@ -48,8 +51,7 @@ The byte code instructions are of variable length and automatically encoded and \endfoot% \bottomrule \endlastfoot% - \texttt{push} & $n~b_0\ldots b_n$ & $st[sp+i] = s[i]$ & $sp+n$ & $pc+2+n$\\ - & & {\bf for all} $i\in\{0..n\}$\\ + \texttt{push} & $n~b_0\ldots b_n$ & $st[sp+i] = s[i]$ {\bf for all} $i\in\{0..n\}$ & $sp+n$ & $pc+2+n$\\ \texttt{pop} & $n$ & & $sp\shortminus{}n$ & $pc+2$\\ \texttt{rot} & $d~n$ & $rotate\:(d, n)$ & $sp$ & $pc+3$\\ \texttt{dup} & & $st[sp] = st[sp\shortminus{}1]$ & $sp+1$ & $pc+1$\\ @@ -60,7 +62,7 @@ The byte code instructions are of variable length and automatically encoded and \texttt{tailCall} & $w_{a_1}~w_{a_2}~l$ & $rotate\:(w_{a_1}+3+w_{a_2},w_{a_2})$ & $fp$ & $jl$\\ & & $fp = fp\shortminus{}w_{a_1}+w_{a_2}$\\ & & \multicolumn{3}{p{.75\textwidth}}{{\bf where} $w_{a_1}$ is the width of the current function and $w_{a_2}$ the width of the called function}\\ - \texttt{arg} & $i$ & $st[sp] = st[fp\shortminus{}1\shortminus{}i]$ & $sp+1$\\ + \texttt{arg} & $n$ & $st[sp] = st[fp\shortminus{}1\shortminus{}n]$ & $sp+1$\\ \texttt{return} & $w_r~w_a$ & $st[fp\shortminus{}w_a\shortminus{}3+i] = st[fp+1]$ & $st[fp\shortminus{}w_a\shortminus{}3+w_r]$ & $st[fp\shortminus{}w_a\shortminus{}1]$\\ & & {\bf for all} $i\in\{0..w_r\}$\\ & & $fp = st[fp\shortminus{}w_a\shortminus{}2]$\\ @@ -68,42 +70,41 @@ The byte code instructions are of variable length and automatically encoded and & & $st[sp+1] = fp$\\ & & $st[sp+2] = 0$\\ \midrule - \texttt{unOp} & & $st[sp\shortminus{}1] = \diamond{}st[sp\shortminus{}1]$ & $sp$ & $pc+1$\\ - & & \multicolumn{3}{l}{{\bf for all} $\diamond\in\{\neg\}$}\\ + \texttt{unOp} & & $st[sp\shortminus{}1] = \diamond{}st[sp\shortminus{}1]$ {\bf for all} $\diamond\in\{\neg\}$ & $sp$ & $pc+1$\\ \texttt{binOp} & & $st[sp\shortminus{}2] = st[sp\shortminus{}2] \mathbin{\oplus} st[sp\shortminus{}1]$ & $sp\shortminus{}1$ & $pc+1$\\ & & \multicolumn{3}{l}{{\bf for all} $\oplus\in\{+, \shortminus{}, *, /, \wedge, \vee, \equiv, \not\equiv, \leq, \geq, <, >\}$}\\ - & & \multicolumn{3}{l}{similar for Real and Long variants}\\ - \texttt{cast}\textsubscript{f-t} & & $st[sp\shortminus{}1] = cast_{f-t} (st[sp\shortminus{}1])$ & $sp$ & $pc+1$\\ + & & \multicolumn{3}{l}{similar for \cleaninline{Real} and \cleaninline{Long} variants}\\ + \texttt{cast}\textsubscript{f-t} & & $st[sp\shortminus{}1] = cast_{f\shortminus{}-t} (st[sp\shortminus{}1])$ & $sp$ & $pc+1$\\ & & \multicolumn{3}{l}{{\bf for all} $f,t\in\{Int, Real, Long\}$}\\ % \pagebreak \texttt{mkTask} & \texttt{Stable\textsubscript{n}} & $st[sp\shortminus{}n\shortminus{}1] = node (stable,$ & $sp\shortminus{}n+1$ & $pc+2$\\ & & $\qquad\qquad st[sp\shortminus{}1], \ldots, st[sp\shortminus{}n\shortminus{}1])$\\ - & \texttt{Unstable\textsubscript{n}} & $st[sp\shortminus{}n\shortminus{}1] = node (unstable,$ & $sp\shortminus{}n+1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{Unstable\textsubscript{n}} & $st[sp\shortminus{}n\shortminus{}1] = node (unstable,$ & $sp\shortminus{}n+1$ & $pc+2$\\ & & $\qquad\qquad st[sp\shortminus{}1], \ldots, st[sp\shortminus{}n\shortminus{}1])$\\ \midrule - & \texttt{ReadD} & $st[sp\shortminus{}1] = node (readd, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ - & \texttt{ReadA} & $st[sp\shortminus{}1] = node (reada, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ - & \texttt{WriteD} & $st[sp\shortminus{}2] = node (writed, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ - & \texttt{WriteA} & $st[sp\shortminus{}2] = node (writea, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ - & \texttt{WriteD} & $st[sp\shortminus{}2] = node (writed, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ - & \texttt{PinMode} & $st[sp\shortminus{}2] = node (pinmode, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{ReadD} & $st[sp\shortminus{}1] = node (readd, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ + \texttt{mkTask} & \texttt{ReadA} & $st[sp\shortminus{}1] = node (reada, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ + \texttt{mkTask} & \texttt{WriteD} & $st[sp\shortminus{}2] = node (writed, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{WriteA} & $st[sp\shortminus{}2] = node (writea, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{WriteD} & $st[sp\shortminus{}2] = node (writed, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{PinMode} & $st[sp\shortminus{}2] = node (pinmode, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ \midrule - & \texttt{Repeat} & $st[sp] = node (repeat, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ - & \texttt{Delay} & $st[sp] = node (delay, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ - & \texttt{And} & $st[sp\shortminus{}1] = node (and, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ - & \texttt{Or} & $st[sp\shortminus{}1] = node (and, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ - & \texttt{Step} $f$ $w_a$ & $st[sp] = node (step, st[sp\shortminus{}1], f, w)$ & $sp$ & $pc+5$\\ + \texttt{mkTask} & \texttt{Repeat} & $st[sp] = node (repeat, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ + \texttt{mkTask} & \texttt{Delay} & $st[sp] = node (delay, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ + \texttt{mkTask} & \texttt{And} & $st[sp\shortminus{}1] = node (and, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{Or} & $st[sp\shortminus{}1] = node (and, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{Step} $f$ $w_a$ & $st[sp] = node (step, st[sp\shortminus{}1], f, w)$ & $sp$ & $pc+5$\\ \midrule - & \texttt{SdsGet} $i$ & $st[sp+1] = node (sdsget, i)$ & $sp+1$ & $pc+3$\\ - & \texttt{SdsSet} $i$ & $st[sp\shortminus{}1] = node (sdsset, st[sp\shortminus{}1], i)$ & $sp$ & $pc+3$\\ - & \texttt{SdsUpd} $i$ $l$ & $st[sp+1] = node (sdsset, i, l)$ & $sp+1$ & $pc+5$\\ + \texttt{mkTask} & \texttt{SdsGet} $i$ & $st[sp+1] = node (sdsget, i)$ & $sp+1$ & $pc+3$\\ + \texttt{mkTask} & \texttt{SdsSet} $i$ & $st[sp\shortminus{}1] = node (sdsset, st[sp\shortminus{}1], i)$ & $sp$ & $pc+3$\\ + \texttt{mkTask} & \texttt{SdsUpd} $i$ $l$ & $st[sp+1] = node (sdsset, i, l)$ & $sp+1$ & $pc+5$\\ \midrule - & \texttt{Interrupt} & $st[sp\shortminus{}2] = node (interrupt, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ - & \texttt{RateLimit} & $st[sp\shortminus{}1] = node (ratelimit, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ - & \texttt{TuneRate} & $st[sp\shortminus{}1] = node (tunerate, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{Interrupt} & $st[sp\shortminus{}2] = node (interrupt, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ + \texttt{mkTask} & \texttt{RateLimit} & $st[sp\shortminus{}1] = node (ratelimit, st[sp\shortminus{}1])$ & $sp$ & $pc+2$\\ + \texttt{mkTask} & \texttt{TuneRate} & $st[sp\shortminus{}1] = node (tunerate, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\ \midrule - & \texttt{DHTTemp} $i$ & $st[sp+1] = node (dhttemp, i)$ & $sp+1$ & $pc+3$\\ - & \texttt{DHTHumid} $i$ & $st[sp+1] = node (dhthumid, i)$ & $sp+1$ & $pc+3$\\ + \texttt{mkTask} & \texttt{DHTTemp} $i$ & $st[sp+1] = node (dhttemp, i)$ & $sp+1$ & $pc+3$\\ + \texttt{mkTask} & \texttt{DHTHumid} $i$ & $st[sp+1] = node (dhthumid, i)$ & $sp+1$ & $pc+3$\\ \end{longtable} \end{landscape} diff --git a/appx/c4hp.tex b/appx/c4hp.tex index 5f8875c..5b8e099 100644 --- a/appx/c4hp.tex +++ b/appx/c4hp.tex @@ -2,15 +2,13 @@ \input{subfilepreamble} -\setcounter{chapter}{0} - \begin{document} \input{subfileprefix} \ifSubfilesClassLoaded{\appendix}{} \chapter{\texorpdfstring{\glsentrytext{CLEAN}}{Clean} for \texorpdfstring{\glsentrytext{HASKELL}}{Haskell} Programmers}% \label{chp:clean_for_haskell_programmers} -This note is meant to give people who are familiar with the \gls{FP} language \gls{HASKELL} a consise overview of \gls{CLEAN} language elements and how they differ from \gls{HASKELL}. +This appendix is meant to give people who are familiar with the \gls{FP} language \gls{HASKELL} a consise overview of the \gls{CLEAN} language elements and how they differ from \gls{HASKELL}. The goal is to support the reader when reading \gls{CLEAN} code. \Cref{tbl:syn_clean_haskell} shows frequently occuring \gls{CLEAN} language elements on the left side and their \gls{HASKELL} equivalent on the right side. Obviously, this summary is not exhaustive. diff --git a/appx/mtask_aux.tex b/appx/mtask_aux.tex index 74273a4..54812ff 100644 --- a/appx/mtask_aux.tex +++ b/appx/mtask_aux.tex @@ -2,11 +2,10 @@ \input{subfilepreamble} -\setcounter{chapter}{1} \begin{document} \input{subfileprefix} -\ifSubfilesClassLoaded{\appendix}{} +\ifSubfilesClassLoaded{\appendix\setcounter{chapter}{1}}{} \chapter{Auxiliary \texorpdfstring{\glsentrytext{MTASK}}{mTask} type classes}% \label{chp:mtask_aux} \lstset{basicstyle=\tt\footnotesize} diff --git a/asbook.tex b/asbook.tex index a6e7816..5e6301d 100644 --- a/asbook.tex +++ b/asbook.tex @@ -4,7 +4,7 @@ \usepackage{pdfpages} \begin{document} -\includepdf[landscape,booklet,pages={1-22}]{thesis.pdf}%chktex 29 chktex 8 -%\includepdf[landscape,booklet,pages={1-}]{top/4iot.pdf}%chktex 29 chktex 8 +%\includepdf[landscape,booklet,pages={1-22}]{thesis.pdf}%chktex 29 chktex 8 +\includepdf[landscape,booklet,pages={1-}]{concl/concl.pdf}%chktex 29 chktex 8 %\includepdf[pages={211,212}]{thesis.pdf}%chktex 29 chktex 8 \end{document} diff --git a/back/acknowledgements.tex b/back/acknowledgements.tex index f065479..c159e0c 100644 --- a/back/acknowledgements.tex +++ b/back/acknowledgements.tex @@ -47,7 +47,7 @@ Michel de Boer, Sjoerd Crooijmans, Willem de Vos. -I give special thanks to my mentors who never stopped having faith me: +I give special thanks to my mentors: Jos Baack, Francisco Torreira, Franc Grootjen, Louis Vuurpijl, and Larry Caruthers. And of course my friends and acquaintances that supported me throughout the process. diff --git a/back/summary.tex b/back/summary.tex index 26e7796..91ee7b7 100644 --- a/back/summary.tex +++ b/back/summary.tex @@ -13,19 +13,18 @@ The number of computers around us is growing exponentially, compounding the comp Many of these computers are \emph{edge devices} operating in \gls{IOT} systems. Within these orchestrations of computers, they interact with the environment using sensors and actuators. Edge devices often use low-cost microcontrollers designed for embedded applications. -They have little memory, unhurried processors, and are slow in communication. -Yet they are small and energy efficient. +They have little memory, unhurried processors, and are slow in communication but are also small and energy efficient. Programming \gls{IOT} systems is complex since they are dynamic, interactive, distributed, collaborative, multi-tiered, and multitasking in nature. -This is impeded more so by semantic friction that arises through different hardware and software characteristics between tiers. +The complexity is increased further by semantic friction that arises through different hardware and software characteristics between tiers. A solution is found in \gls{TOP}. %A solution is found in the declarative programming paradigm \gls{TOP}.%, a declarative programming paradigm. In \gls{TOP}, the main building blocks are tasks, an abstract representation of work. During execution, the current value of the task is observable, and other tasks can act upon it. -Collaboration patterns can be modelled by combinding and transforming tasks into compound tasks. -From this declarative description of the work, a ready-for-work computer system is generated that guides the user in doing the work. +Collaboration patterns can be modelled by combining and transforming tasks into compound tasks. +From this declarative description of the work, a ready-for-work computer system is generated that guides all operators in doing the work. An example of a \gls{TOP} system is \gls{ITASK}, a language which describes interactive web applications. -Programming edge devices would benefit from \gls{TOP} as well. +Programming edge devices benefits from \gls{TOP} as well. However, it is not straightforward to run \gls{TOP} systems on resource-constrained edge devices. This dissertation demonstrates how to orchestrate complete \gls{IOT} systems using \gls{TOP}. @@ -39,8 +38,7 @@ For a device to be used in an \gls{MTASK} system, it must to be programmed once This \gls{OS} executes tasks in an energy-efficient way and automates all communications and data sharing. All aspects of the \gls{MTASK} system are shown: example applications, language design, implementation details, integration with \gls{ITASK}, and green computing facilities. When using \gls{MTASK} in conjunction with \gls{ITASK}, entire \gls{IOT} systems are programmed tierlessly from a single source, language, paradigm, high abstraction level, and type system. -The dissertation concludes with a comparison between tierless programming, in particular in \gls{MTASK}, and traditional tiered programming. -It demonstrates that many problems such as semantic friction, maintainability, robustness, and interoperation safety are mitigated when using tierless programming. +Many problems such as semantic friction; maintainability and robustness issues; and interoperation safety are mitigated when using tierless programming. %This is a summary of 350--400 words. %\end{center} \end{document} diff --git a/concl/concl.tex b/concl/concl.tex index c454398..cfbb92a 100644 --- a/concl/concl.tex +++ b/concl/concl.tex @@ -20,7 +20,7 @@ The complexity mainly arises from the fact that each layer of the system is buil This generates a lot of semantic friction. Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative. \Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems. -However, edge devices are often too computationally restricted to be able to run traditional \gls{TOP} systems. +However, edge devices are often too computationally restricted to be able to run a full-fledged \gls{TOP} system such as \gls{ITASK}. This thesis sheds light on how to orchestrate complete \gls{IOT} systems using \gls{TOP}. It specifically fills in the knowledge gap for edge devices. The contributions are split up into three episodes. @@ -38,7 +38,7 @@ The scaffolding is generated using template metaprogramming and quasiquotation i \Cref{prt:top} contains a complete overview of the \gls{MTASK} system: its design, integration with \gls{ITASK}, implementation, and green computing facilities. The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices. -The system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications. +The \gls{MTASK} system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications. In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows. The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling. Tasks in the \gls{MTASK} system are compiled at run time and sent to the device dynamically in order to support create dynamic systems where tasks are tailor-made for the current work requirements. @@ -54,11 +54,12 @@ The comparison demonstrates that programming such complex systems using a tierle Concretely, it results in fewer \gls{SLOC}, files, programming languages and programming paradigms. However, it is not a silver bullet. +However, it has some disadvantages as well. Tierless languages are novel, and hence lacking tooling and community support. They contain many high-level tierless abstractions that the programmer has to master. The low-level specific semantics of the final application may become more difficult to destill from the specification. Finally, the system is quite monolithic. -Changing components within the system is easy if it already exists in the host language. +Changing components within the system is easy if it already is supported in the \gls{EDSL}. Adding new components to the system requires the programmer to add it to all complex components of the languages such as the compiler, and \gls{RTS}. \input{subfilepostamble} diff --git a/glossaries.tex b/glossaries.tex index fc8ffe7..edae456 100644 --- a/glossaries.tex +++ b/glossaries.tex @@ -71,7 +71,7 @@ } \newglossaryentry{MTASK}{% name=mTask, - description={- a \glsxtrshort{TOP} \glsxtrshort{EDSL} for microcontrollers integrated with the \gls{ITASK} system}, + description={- a \glsxtrshort{TOP} \glsxtrshort{EDSL} for edge devices integrated with the \gls{ITASK} system}, } \newglossaryentry{ITASK}{% name=iTask, diff --git a/top/finale.tex b/top/finale.tex index 34e0131..8738588 100644 --- a/top/finale.tex +++ b/top/finale.tex @@ -9,7 +9,7 @@ \chapter{Finale}% \label{chp:finale} \begin{chapterabstract} - \noindent This chapter wraps up the monograph by means of: + This chapter wraps up the monograph by means of: \begin{itemize} \item a conclusion; \item an outlook on future work; @@ -19,26 +19,27 @@ \end{chapterabstract} \section{Finale} -Traditionally, \gls{IOT} have been programmed using layered architectures. +Traditionally, \gls{IOT} has been programmed using layered, or tiered, architectures. Every layer has its own software and hardware characteristics, resulting in semantic friction. -\Gls{TOP} is a declarative programming paradigm designed for specifying multi-tiered interactive systems. +\Gls{TOP} is a declarative programming paradigm designed to describe multi-tiered interactive systems. However, it is not straightforward to run \gls{TOP} systems on resource-constrained devices such as edge devices. The \gls{MTASK} system bridges this gap by providing a \gls{TOP} programming language for edge devices. -It is a full-fledged \gls{TOP} language hosted in a tiny functional programming language containing basic tasks, task combinators, support for sensors and actuators, and interrupts. -It is integrated seamlessly in \gls{ITASK}, a \gls{TOP} system for interactive web applications. +It is a full-fledged \gls{TOP} language hosted in a tiny \gls{FP} language. +Besides the usual \gls{FP} constructs, it contains basic tasks, task combinators, support for sensors and actuators, and interrupts. +It integrates seamlessly in \gls{ITASK}, a \gls{TOP} system for interactive web applications. Hence, all layers of an \gls{IOT} system can be programmed from a single declarative specification. -\Gls{ITASK} abstracts away from the gritty details of interactive web applications such as program distribution, web applications, data storage, and user management. -The engine of \gls{MTASK} abstracts away of all technicalities such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling. +In \gls{ITASK}, abstraction are available for the gritty details of interactive web applications such as program distribution, web applications, data storage, and user management. +The engine of \gls{MTASK} abstracts away of all technicalities specific to edge devices such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling. -The \gls{MTASK} devices are connected to the \gls{ITASK} system at run time using a single function that takes care of all the communication and error handling. Any device equipped with the \gls{MTASK} \gls{RTS} can be used in the system and dynamically receive tasks for execution. This domain-specific \gls{OS} only needs to be programmed once, hence saving precious write cycles on the program memory. +The \gls{MTASK} devices are connected to the \gls{ITASK} system at run time using a single function that takes care of all the communication and error handling. Once connected to a device, tasks written in the \gls{MTASK} \gls{DSL} can be lifted to \gls{ITASK} tasks. -The tasks are specified and compiled at run time, i.e.\ \gls{CLEAN} can be used as a macro language for constructing \gls{MTASK} tasks, tailor making them for the work that needs to be done. +The tasks are specified and compiled at run time, i.e.\ \gls{CLEAN} can be used as a macro language for constructing \gls{MTASK} tasks, tailor making them for the current work requirements. When lifted, other tasks in the system can interact with the task through the usual means. -Furthermore, \gls{ITASK} \glspl{SDS} can be \emph{lowered} to \gls{MTASK} tasks as well, allowing for bidirectional automatic data sharing between \gls{MTASK} tasks and the \gls{ITASK} system. -\todo[inline]{Uitbreiden} +Furthermore, \gls{ITASK} \glspl{SDS} can be \emph{lowered} to \gls{MTASK} tasks as well, allowing for bidirectional automatic data sharing between \gls{MTASK} tasks and the \gls{ITASK} system irrespective of task relations. +\todo{Uit\-brei\-den?} \section{Future work} \todo[inline]{De grens tussen future en related work is soms vaag maar ik heb het zo goed als mogelijk proberen te scheiden. Mis ik hier nog iets?} diff --git a/top/int.tex b/top/int.tex index 4b9c3c1..1ef5860 100644 --- a/top/int.tex +++ b/top/int.tex @@ -145,6 +145,8 @@ liftmTask task (MTDevice dev sdsupdates channels) -|| watchSharesUpstream mrefs channels tid) \end{lstClean} +\todo{dis\-cuss pre\-loading} + \section{Lifting \texorpdfstring{\gls{ITASK}}{iTask} \texorpdfstring{\glsxtrlongpl{SDS}}{shared data sources}}\label{sec:liftsds} Lifting \gls{ITASK} \glspl{SDS} to \gls{MTASK} \glspl{SDS} is something that mostly happens at the compiler level using the \cleaninline{liftsds} function (see \cref{lst:mtask_itasksds}). \Glspl{SDS} in \gls{MTASK} must always have an initial value.