That is one problem, no? The monolith.c is what I was trying to run away
from...
2007/10/3, Kevin Klues [EMAIL PROTECTED]:
Don't forget that all your nesC modules just get turned into one giant
app.c file in your build/platform directory if thats useful.
Kevin
On 10/3/07, Bernardo Avila Pires [EMAIL PROTECTED] wrote:
Hi, I would like to ask some questions and expose some ideas of mine.
1) How many people might need a simulator for more than one
application?
2) How many people might use simulators as means of debugging their
application?
3) How many people might use simulators to evaluate application
performance
and behavior?
I found myself in need of a simulator to debug the algorithms for
interaction between two applications. So I posted a question about how
to
hammer to applications in TOSSIM and later I had an idea. So, how hard
would
it be to translate nesC to C++? Given C++ code for components, it would
be
possible to build and use a NS-like simulator, no? So I kept thinking
about
this translation process:
There could be two ways to bind components via interface: by
generating
code for the bindings (static) or by passing objects (which would be
instances of components) as parameters to other objects in execution
time
(dynamic). Also, statically bound interfaces could be inspected many
times
in order to remove indirection levels. Some low-level components would
need
to be implemented as C++ code integrated to the simulator if efficiency
during simulation were important, otherwise the simulator could emulate
the
nodes right away.
I have to put more thought on the other ideas I have.
Regards,
Bernardo
--
The truth shall set you free
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
~Kevin
--
The truth shall set you free
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
