[Tinyos Core WG] two random tool things

[Philip Levis]

Can we move these discussions on -devel?

Phil

On Mar 31, 2009, at 3:59 PM, Kevin Klues wrote:

> 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
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg