[Tinyos Core WG] TOSThreads TEP

[John Regehr]

> Regarding interrupts using the current thread stack: this kills static
> stack depth analyzers,

Not true...

The crux is separating out the problems:
1. computing WC stack depth for sequential code
2. putting sequential results together based on how the system works

#1 is the harder problem and it is nearly orthogonal to system-level 
issues like threads, interrupts, etc. that affect #2.

In a bit more detail:

let
   Di = WC stack depth of interrupt handlers
   Dt = max WC stack depth over all tasks
   Dtn = WC stack depth of thread n
   N = number of threads

For current TinyOS WC stack depth is

   Dt + Di

For Kevin's current system WC stack depth is

   Dt + Di + sum x=1..N (Dtx + Di)

When you run TinyOS not in a thread WC stack depth is:

   sum i=1..N (Dti + Dt + Di)

With a kernel stack WC stack depth is:

   Dt + Di + sum x=1..N (Dtx)

I am leaving out a few small constant factors but you get the idea. 
Before settling on an execution model for TOSThreads it would be nice to 
plug in the numbers for some big applications (which of course don't 
exist yet...).

BTW I still plan to add a stack tool into TinyOS.  It largely works, 
just haven't had time to finish it up and test it.

> Is it absolutely necessary that an epilogue be specified for _all_
> interrupt handlers? My guess is that the system would not break if you
> allowed bursts of interrupts without the epilogues if it is guaranteed
> that the burst is closely followed by an interrupt the handler of which
> does have an epilogue.

This sounds risky.  Preferable would be for Kevin to put some elbow 
grease into the epilogue and make the fast path <10 cycles.  Feasible Kevin?

> You make use of function pointers pretty extensively. Is there a reason
> why they couldn't be replaced with interface parameters? Parameterized
> interfaces are in line with the TinyOS/nesC philosophy, and also,
> getting rid of function pointers would make the job of analysis tools
> much easier.

Amen.

John