Warren and Christoph,
I've been testing with the Fibers and Zilch libraries and following your discussion. I find the Fibers example builds and runs on T3.2, but won't build on T3.5 due to missing "fiber_getsp" and "_sstack". I've also searched and have been unable to find "fiber_getsp" anywhere, so I don't know how that is being resolved for T3.2. My fix has been to delete the instrumentation, which I think is useful but not necessary. With that small change, Fibers builds and runs for T3.2, and at least builds for T3.5. I can run it tomorrow.
I have also made one small change to what you call the "rounding" of stack size to word boundary.
stack_size = ( stack_size + sizeof (uint32_t) ) / sizeof (uint32_t) * sizeof (uint32_t);
When stack_size is on a word boundary, your code increases the size of the stack by 4 bytes, which I don't think you intended. I think it would be better to use this code, which rounds stack_size down if it's not on a uint32_t boundary:
stack_size = ( stack_size / sizeof (uint32_t) ) * sizeof (uint32_t);
I'm working on a set of mailbox, queue, semaphore, etc. functions as an optional extension to fibers. Fibers can pend on mailboxes, etc. with a timeout, and ISRs can signal fibers via mailboxes, etc.
Zilch has support for both 3.x and LC in one set of files, which would be useful to duplicate in Fibers. While Zilch does build for both T3.2 and T3.5, I prefer the simpler API of Fibers. In my own experience with cooperative executives that include mailboxes, etc., I've always been able to get by without ending, pausing, or resuming tasks. That can all be done by having them pend on signals.
Joe