\subsection{Simulation}
An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
works in the same way as the existing \gls{C}-backed simulation. It simulates
-the bytecode interpretation. Moreover would be possible to let the simulator
+the bytecode interpretation. Moreover, it would be possible to let the simulator
function as a real device, thus handling all communication through the
existing \gls{SDS}-based systems and behave like a real device. At the moment
the \emph{POSIX}-client is 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 accurately on some levels. The semantics can
-be simulated but timing and peripheral input/output are more difficult to
-simulate properly.
+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.
\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 \glspl{mTask} get slices
-of execution time and will each have their own interpreter state instead of one
-system-wide one that is reset after am \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 the server knows
-the multithreading capabilities of the client.
+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} 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 the server
+knows the multithreading capabilities of the client.
\paragraph{Optimizing the interpreter:}
-Hardly any work has been done in the interpreter. The current interpreter is a
-no nonsense stack machine. A lot of improvements can be done in this part. For
-example, precomputed \emph{gotos} can improve jumping to the correct part of
-the code corresponding to the correct instruction. Moreover, the stack
-currently consists of 16-bit values. All operations work on 16-bit values and
-this simplifies the interpreter implementation. A memory improvement can be
-made by converting the stack to 8-bit values. This does pose some problems
-since an equality instruction must work on single-byte booleans \emph{and}
-two-byte integers. Adding specialized instructions per word size could overcome
-this problem.
+Due to time constraints and focus, hardly any work has been done in the
+interpreter. The current interpreter is a no nonsense stack machine. A lot of
+improvements can be done in this part. For example, precomputed \emph{gotos}
+can improve jumping to the correct part of the code corresponding to the
+correct instruction. Moreover, the stack currently consists of 16-bit values.
+All operations work on 16-bit values and this simplifies the interpreter
+implementation. A memory improvement can be made by converting the stack to
+8-bit values. This does pose some problems since an equality instruction must
+work on single-byte booleans \emph{and} two-byte integers. Adding specialized
+instructions per word size could overcome this problem.
\subsection{Resources}
\paragraph{Resource analysis: }
systems can be designed. When the system knows precise bounds it can allocate
more \glspl{Task} on a device whilst staying within safe memory bounds. The
resource allocation can be done at runtime within the backend itself or a
-general backend can be devices that can calculate the resources needed for a
+general backend can be devised that can calculate the resources needed for a
given \gls{mTask}. A specific \gls{mTask} cannot have multiple views at the
same time due to the restrictions of class based shallow embedding. It might
even be possible to encode the resource allocation in the type system itself
\paragraph{Launch \glspl{Task} from a \gls{Task}: }\label{par:tasklaunch}
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 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 communication
-protocol since relations between \glspl{Task} also need to be encoded and
-communicated.
+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
+communication protocol since relations between \glspl{Task} also need to be
+encoded and communicated.
The \gls{SDS} functionality in the current system is bare. There is no easy way
-of reusing a \gls{SDS} for another \gls{Task} on the same device or on another
+of reusing an \gls{SDS} for another \gls{Task} on the same device or on another
device. Such functionality can be implemented in a crude way by tying the
\glspl{SDS} together in the \gls{iTasks} environment. However, this will result
in a slow updating system. Functionality for reusing shares from a device
\subsection{Robustness}
\paragraph{Reconnect with lost devices:}
The robustness of the system can be greatly improved. Devices that lose
-connection are in the current system not well supported. The device will stop
-functioning and have to be emptied for a reconnect. \Glspl{Task} residing on a
+connection are not well supported in the current system. The device will stop
+functioning and has to be emptied for a reconnect. \Glspl{Task} residing on a
device that disconnected should be kept on the server to allow a swift
reconnect and restoration of the \glspl{Task}. This holds the same for the
client software. The client drops all existing \glspl{Task} on a shutdown
to the peripherals. The semantics of the \glspl{mTask} tries to resemble the
\gls{iTasks} semantics as close as possible.
-The host language has a very efficient compiler and code generator. Therefore,
+The host language has a proven efficient compiler and code generator. Therefore,
compiling \glspl{mTask} is also fast. Compiling \glspl{mTask} is nothing
more than running some functions native to the host language.
repositories / msc-thesis1617.git / commitdiff