Re: [avr-gcc-list] task/thread stack usage

[Larry Barello]

This seems like a minor improvement.  It doesn't support nesting of
interrupts, although, I suppose, each handler can have it's own stack.
Even then, it doesn't support a re-entrant interrupt handler (and I
have done that more than once...)  It doesn't support RTOS
requirements either since swapping the stack is the minor operation;
saving context is the big one.  If each handler has it's own stack,
then why not just put all that into the main stack?  If you have
multiple task stacks, then you need to save context when swapping so
the SP change becomes the minor one.  For me, the only benefit is that
I can move non-RTOS managed interrupts onto their own stack and
unburden the task stacks.  However, non-RTOS handlers typically (for
me) use very little stack as they are small, very high speed, things
so the cost is minimal.

I don't know how ethernut, bdmicro or Tvrktko do their interrupt
handling - apparently I am the only one who saves the entire context
prior to entering the code that might cause a context switch.  Even if
I delayed the context switch until I needed it, that would leave an
unspecified amount of junk on the interrupt handler stack which would
have to be copied onto the user stack, or restored or something.
Anyway, I decided the overhead of a 1/2 context switch upon entry into
RTOS managed interrupt handlers was a decent trade off between overall
cycles and code size and SRAM footprint (I originally developed on a
2313, so SRAM footprint was  a pretty big {small} concern... :)

Cheers!

----- Original Message -----
From: "Marek Michalkiewicz" <address@hidden>
>
> `sp_switch'
>      Use this attribute on the SH to indicate an `interrupt_handler'
>      function should switch to an alternate stack.  It expects a
string
>      argument that names a global variable holding the address of
the
>      alternate stack.
>
>           void *alt_stack;
>           void f () __attribute__ ((interrupt_handler,
>                                     sp_switch ("alt_stack")));
>
> Basically it works like this: interrupt prologue saves the stack
> pointer in registers, sets SP to the value of the alt_stack
variable,
> and pushes the old SP value on the new stack (so that SP is easily
> restored in the epilogue).  All "signal" functions (running with
> interrupts disabled) can share one alternate stack.  Interrupt
> handlers running with interrupts enabled must have their own stacks.
>
> I think this would be nice to have on the AVR as well - added to my
> GCC 3.4 TODO list...