[Tinyos Core WG] two random tool things

[Kevin Klues]

I can only see two ways to avoid compiling twice in the case of
determining the TOSThreads stack sizes.  Both involve the use of
something like tos-set-symbols.

(1) Statically allocated stacks:  Initialize all thread stacks to size
1 in the intiial compile and place them at the end of the bss section
of the elf binary.  Then invoke the stack depth analysis tool to
determine the maximum stack depths for each thread and expand the
stack for each thread in the elf binary.  I'm not sure how difficult
this is, as I'm not an expert on the elf binary format.  I assume this
involve more than simply packing more 0's onto the binary somehwere as
te stack expands.

(2) Dynamically allocated stacks: Right now all stacks in the nesC
interface are statically allocated.  We could modify these semantics
to force all stacks to be allocated dynamically, even if this only
once at the start of the program.  This would then involve simply
changing a variable and could simply leverage the existing
tos-set-symbol script.

Ideally, I'd prefer the first, but the second is also viable.  Both
approaches will need some way of detecting that the computed stack
sizes are not so large that the binary exceeds the size of the flash
on the platform.

Kevin

On Tue, Mar 31, 2009 at 3:41 PM, John Regehr <regehr at cs.utah.edu> wrote:
> For incidental reasons we've been using avr-gcc pre-4.4.0, which is
> quite good: it seems to have fewer bugs and it generates better code.
> Considering apps in the CVS HEAD, binaries from pre-4.4.0 are about 5%
> smaller than the 4.1.2 that came out with TinyOS 2.1.  Oddly, Safe
> TinyOS binaries only get about 2.5% smaller, we don't know what is going
> on.  We have not looked at avr-gcc 4.2, and don't plan to.  4.3 produces
> binaries several percent larger than 4.1 and so is unlikely to be worth
> considering.
>
> Summary: it's probably worth upgrading to 4.4 at some point.
>
> Second, I'm finally dusting off my stack depth analysis tool and making
> sure it can analyze all applications for AVR platforms (msp430 isn't
> hard to support but with 10 KB of RAM I don't think this is critical).
> I'd like to check this into TinyOS and make it easily invokable by
> adding a stack-check.extra makefile target, or similar.  Any objections?
>  It is a Perl script and has no exotic dependencies.
>
> The stack tool does not yet compute stack sizes for TOSThreads apps.
> Kevin we should talk sometime about how to best do that.  The problem is
> that we don't know stack requirements of threads until after avr-gcc has
> run, at which point it is too late to plug these depths into the app.
> Compiling twice seems inelegant.  One possibility is to edit the binary
> a bit like in tos-set-symbols.
>
> John
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>



-- 
~Kevin