[Tinyos Core WG] TOSThreads TEP

[Kevin Klues]

> This is great work, I can't wait seeing it. Please see my comments
> below.
>
> 1. Readiness for static stack depth analysis
>
> Regarding interrupts using the current thread stack: this kills static
> stack depth analyzers, which would be really great to have in the
> future.

I think Jon's comments address this pretty well.  And I agree, the
best long term solution is to have the TinyOS stack and interrupts run
on a shared stack, removing the need for them to duplicate the space
allocated for handling interrupts.

> 2. Epilogue requirement

I agree that this is pretty risky to not have it at the bottom of each
handler.  I'm sure there is a way to streamline the cost here as John
suggests, but right now (on the msp430) it takes a couple hundered
cycles.....

> 3. Function pointers
>
> You make use of function pointers pretty extensively. Is there a reason
> why they couldn't be replaced with interface parameters?

The primary motivation for using function pointers was to provide the
ability to write an entire application in standard c instead of in
nesC.  Of course, function pointers wouldn't be necessary if we
supported only Static threads (using terminology borrowed from the
TEP), to allow flexibility in the definition and use of dynamic
threads, function pointers are necessary.

Maybe the answer to helping write static analysis tools given the
presence of function pointers is to add annotations to functions
potentially callable via a function pointer.  Only those functions
with proper annotations could ever have their address assigned to a
variable.

> 4. Misc comments
>
> Section 3.3: AFAIK, on the atmega128, the stack grows from higher memory
> locations to lower memory locations. Please correct me if I'm wrong.

I'll have to double check this, but in my current implementation, I
have them growing up.  Maybe I've jsut been lucky and haven't somehow
crossed any undesired memory boundaries.  TOSThreads is only currently
tested extensively on telosb and I'm still in the process of porting
it to the micas and eventually to the imote.  This may be the cause of
some of the bugs I'm seeing right now.....

> Also, you have a couple of references to section 3.2, which, I guess,
> should refer to section 4.2.

Easily fixed.

Kevin