Design and Implementation of TinyGALS: A Programming Model for ...

7.1 Future Work
We plan to reimplement the TinyGALS syntax and code generation tools to be compatible
with nesC [18], the language written for TinyOS v1.0 and higher. We will then be able
to take advantage of additional type checking provided by the nesC compiler. nesC will
probably allow us to create a better way of declaring use of TinyGUYS global variables
with scoping. David Culler notes that the TinyGALS scheduler could be implemented as
a TinyOS task that posts itself and contains code to transfer data between components and
activate them. We plan to investigate the feasibility of this approach with respect to the
generation of code for TinyGALS module input ports.
We also plan to investigate how TinyGALS relates to the CI domain in Ptolemy II and
how this can be leveraged to create a TinyGALS domain or runtime system, similar to that
of TM.
Various improvements could be made to the TinyGALS framework. For example, a
mechanism for writing to input ports whose queues are full could be added so that writes
are blocking and will retry later when the queue is not full. The basic FIFO scheduling of
modules in TinyGALS could be replaced with a priority scheduling algorithm with queue
insertions.
We also wish to investigate the possibility of run-time reconfigurability of modules
– how to replace or reconfigure modules in a TinyGALS system while it is executing.
Another important direction of research is distributed multi-tasking, in which TinyGALS
could be extended to execute in a distributed fashion on multiple nodes, rather than its
current single-node implementation. An interesting area to investigate is that of heterarchy
[16], in which components may belong to multiple concurrent and cross-cutting networks.
59