> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of John Regehr > Sent: Monday, January 14, 2008 8:12 PM > To: [email protected] > 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 _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
