[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] TOS2 tasks code size

[Cory Sharp]

Ah.  I think the big switch statement *is* reasonably efficient. 
After mangling and observing various app.c's, a dominating reason why
using TOS2 tasks can produce larger binaries is ...

1) TinyOS 1.x tasks: any task defined but never posted is elided by nesC.

2) TinyOS 2.x tasks: no tasks are elided, all defined tasks are
compiled, including functions only ever invoked by those tasks.

In the sample application I was using, 5 out of its 22 tasks that were
never posted.  Those 5 were elided from the TOS1 tasks application and
included in the TOS2 tasks application.

Cory


On 10/8/05, Cory Sharp <cory at moteiv.com> wrote:
> On 10/8/05, Philip Levis <pal at cs.stanford.edu> wrote:
> > On Oct 5, 2005, at 1:00 PM, Cory Sharp wrote:
> >
> > > One small thing that been bothering me is that TinyOS 2.x tasks
> > > compile to slightly larger code than TinyOS 1.x tasks, but my
> > > expectation is TOS2 tasks should take the same or less space.  I can't
> > > quite figure out where the space is going, and I wonder if anyone else
> > > has any ideas as to what's causing the minor bloat.
> >
> > Hrm. Looking at the code, this doesn't seem totally crazy. The T2
> > code is definitely more lines and has more cases. Have you looked at
> > the assembly?
> >
> > When I put the T2 code in there, all I really did was copy your
> > example code from reserved tasks. I will take a look on Sunday and do
> > a code review pass to see if I can cut the code down. It might be
> > useful if we iterated once more after that (you take a look at my
> > code and try to cut *it* down).
>
> I've done a pass over it and was only able to make minor improvements.
>
> I was talking to David G about it a couple of days ago.  My intuition
> is that the dispatch to the case statements (with inlined task bodies)
> should take less space than the sum of per function prelude and
> prologue.  But, I think my intuition is wrong.  Though, I'd have to
> carefully peruse the assembly code to understand exactly why.
>
> Another experiment could be to mangle an app.c to invoke the tasks
> through a static const function pointer array rather than through a
> switch statement, and see if that offers any improvement.  If that
> helps, that would indicate the dispatch is the place to optimize,
> rather than the rest of the scheduler code.
>
> Cory
>

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg