Re: [avr-gcc-list] New function attribute idea

[Larry Barello]

How are you going to handle nested interrupts?

I have implemented this in my RTOS and it isn't trivial and it takes
some ~200 cycles or more to do a context switch since you need to keep
track of when you are on the interrupt stack and how deep you are,
performing the task stack restore only when the interrupts unwind.

Anyway, you can check out what I did at http://www.barello.net/avrx

If all you want is a single, non-interruptible, global signal function
in your project, just do the prologue an epilog by hand in assembly -
don't use the C construct, or, use the "noreturn" attribute + your
assembly fragment to swap stacks.

Cheers!

----- Original Message -----
From: "Tvrtko A. Ursulin" <address@hidden>
To: <address@hidden>
Sent: Wednesday, January 15, 2003 12:38 AM
Subject: [avr-gcc-list] New function attribute idea


>
> Hello everyone!
>
> I will try to explain some new functionality I am planning to
implement in
> avr-gcc.
>
> Imagine the following situation: We have an kernel, two tasks, and
one
> interrupt. Kernel has its own stack space, as well as each task. The
> situation in RAM looks like this:
>
> <Top of RAM>
> [Kernel stack]
> [Task 1 stack]
> [...]
> [Task N stack]
> <free RAM>
>
> If we have an interrupt which needs some stack space itself, we must
expand
> each of the task stack space (and kernel space), to accomodate
possible
> interrupt. But interrupt can happen only once at a time, so we have
wasted
> IRQ_STACK_SIZE*NUMBER_OF_TASKS bytes of RAM.
>
> What would I like to have is a enhanced "signal" function attribute,
let's
> call it "global_signal". That kind of function should change SP as a
first
> thing in it's prologue. Then we'd have situation like this:
>
> <Top of RAM>
> [Global interrupt SP storage]
> [Global interrupt stack]
> [Kernel stack]
> [Task 1 stack]
> [...]
> [Task N stack]
> <free RAM>
>
> As "global_signal" must be able to restore original SP, it will use
1 bytes of
> "normal" stack space (to save __tmp_reg__ it needs to initialitze
properly).
> But we still save possibly much space. Because we only must expand
each tasks
> stack size by 1 (and kernel stack also).
>
> Without this functionality, we have to expand each stack with as
much as is
> needed for biggest global interrupt.
>
> The prologue of this function should look like this (possible bad
operand
> usage):
>
> push __tmp_reg__
> in SP_L, __tmp_reg__
> sts GLOBAL_IRQ_SP_L_STORAGE, __tmp_reg__
> in SP_H, __tmp_reg__
> sts GLOBAL_IRQ_SP_H_STORAGE, __tmp_reg__
> out SP_L, GLOBAL_IRQ_STACK_L
> out SP_H, GLOBAL_IRQ_STACK_H
>
> and now proceed with almost normal "signal" prologue, but without
saving
> __tmp_reg__ as it is already saved.
>
> Epilogue:
>
> Do standard "signal" epilogue only without restoring __tmp_reg__
>
> lds GLOBAL_IRQ_SP_H_STORAGE, __tmp_reg__
> out SP_H, __tmp_reg__
> lds GLOBAL_IRQ_SP_L_STORAGE, __tmp_reg__
> out SP_L, __tmp_reg__
> pop __tmp_reg__
>
>
> I hope so far it is clear to everyone what I am trying to do.
>
> Now the problems:
>
> I am not fully competent to make such a complicated(?) patch. I
don't have a
> clue how to make prologue and epilogue which don't use fixed RAM
addresses
> for GLOBAL_IRQ_ variables, but can use symbols which can later be
resolved by
> someone else. My idea is that addresses are like this:
>
> GLOBAL_IRQ_SP_L_STORAGE = RAMEND
> GLOBAL_IRQ_SP_H_STORAGE = RAMEND - 1
> GLOBAL_IRQ_STACK_L = RAMEND - 2
> GLOBAL_IRQ_STACK_H = RAMEND - 3
>
> Is it possible for gcc to know what is RAMEND based on --mmcu
parameter on
> compilation time, and do this correctly?
>
> Any comments are welcome and appreciated! (and patches too!) ;)
>
>
> avr-gcc-list at http://avr1.org
>

avr-gcc-list at http://avr1.org