RE: AVR Benchmark Test Suite [was: RE:[avr-gcc-list]GCC-AVRRegisteroptimisations]

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of John Regehr
> Sent: Monday, January 14, 2008 8:12 PM
> To: address@hidden
> Subject: RE: AVR Benchmark Test Suite [was: 
> RE:[avr-gcc-list]GCC-AVRRegisteroptimisations]
> 
> > Is this program designed for general purpose AVR 
> applications? Or just
> > for TinyOS?
> 
> The answer is unfortunately a bit subtle...
> 
> The question is, how clever of an analysis do you want?  This 
> tool (and 
> mine) attempt to be clever by inferring that at some program points, 
> interrupts are disabled, which eliminates that possibility of that 
> interrupt consuming extra stack RAM right there.
> 
> Bill's tool exploits the fact that nesC guarantees that 
> interrupts are 
> disabled using specific function calls and also that these 
> are lexically 
> nested.  An example of code that is does not have lexically nested 
> critical sections is one where you call a function with 
> interrupts enabled 
> and it returns with interrupts disabled.  You can do this if 
> you want but 
> few developers would do it on purpose.
> 
> Anyway the upshot is that if you make the analysis a bit less 
> clever (and 
> therefore a bit less precise) Bill's tool should work fine on 
> generic AVR 
> codes.  I'll ping him and see if he'll add an option that does this.

In the interest of having a working, general-purpose AVR stack analysis
tool, I would think that it is ok to make certain assumptions, as long
as those are declared to the end-user, that make the analysis easier and
workable. For example, let's assume that any AVR application does not
nest interrupts. This is a fairly reasonable assumption; there is rarely
a case where an AVR application is *desgined* to do that (by accident,
yes, usually as a case of mis-writing a uart driver). Then wouldn't the
stack analysis boil down to: worst-case stack depth of call tree +
worst-case stack depth of the ISRs? The only complication then would be
dealing with indirect calls, yes?
 
> Stack depth analysis should definitely be a part of an AVR 
> test suite.  It 
> should also be in most developers' compilation toolchain but that's a 
> different argument.

But not unrelated. At this point, I'd just like to have a tool that
works for general-purpose AVR applications, and not just geared towards
TinyOS.

Eric Weddington