-The system is still a crude prototype and a proof of concept. Improvements and
-extension for the system are amply available in several fields of study.
+The novel system is functional but still a crude prototype and a proof of
+concept. The system shows potential but improvements and extensions for the
+system are amply available in several fields of study.
\subsection{Simulation}
An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
the reference client and contains debugging code. Adding a simulation view to
the system allows for easy interactive debugging. However, it might not be
easy to devise a simulation tool that accurately simulates the \gls{mTask}
-system on some levels. The semantics can be simulated but timing and peripheral
-input/output are more difficult to simulate properly.
+system on some levels. The execution strategy can be simulated but timing and
+peripheral input/output are more difficult to simulate properly.
\subsection{Optimization}
\paragraph{Multitasking on the client:}
True multitasking could be added to the client software. This allows
\gls{mTask}-\glspl{Task} to run truly parallel. All \gls{mTask}-\glspl{Task}
get slices of execution time and will each have their own interpreter state
-instead of a single system-wide state which is reset after am \gls{mTask}
+instead of a single system-wide state which is reset after an \gls{mTask}
finishes. This does require separate stacks for each \gls{Task} and therefore
increases the system requirements of the client software. However, it could be
implemented as a compile-time option and exchanged during the handshake so that
Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
the current system this type of logic has to take place on the server side.
Adding this functionality to the bytecode-view allows greater flexibility,
-easier programming and less communication resources. Adding these semantics
-requires modifications to the client software and extensions to the
+easier programming and less communication resources. Adding this type of
+scheduling requires modifications to the client software and extensions to the
communication protocol since relations between \glspl{Task} also need to be
-encoded and communicated.
+encoded and communicated. A similar technique as used with \glspl{SDS} has to
+be used to overcome the scoping problem.
The \gls{SDS} functionality in the current system is bare. There is no easy way
of reusing an \gls{SDS} for another \gls{Task} on the same device or on another
repositories / msc-thesis1617.git / blobdiff