\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}
\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$\\
\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]$\\
& & $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}
\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.
\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}
\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}
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.
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}.
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}
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.
\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.
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}
}
\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,
\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;
\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?}
-|| 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.
repositories / phd-thesis.git / commitdiff