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

[Tvrtko A. Ursulin]

On Wednesday 15 January 2003 15:17, Larry Barello wrote:

> How are you going to handle nested interrupts?

I don't need them so that simplifies things a lot.

> 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

I think I have already looked at it, but I am still making my own. Not that I 
think your code is not good, I simply enjoy making it and learning :) So far 
my RTOS is very efficient, both regarding to memory usage and speed. And 
everything (99%) is in pure C. Still, task/context switch takes only 237 
cycles. That is with basic kernel support, it takes some cycles more if 
"jiffies" (schedule_timeout, sleep_on_timeout, wake_up) or RTC support is 
compiled in. Notice that I am "emulating" linux API very closely.

I don't want to push all 32 registers on the stack on every interrupt, I want 
to do it intelligently. I think that could be easily done with my patch (yet 
to be made). It would enable my RTOS to use even less memory.

> 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.

No, I need that for all of my interrupts. 

And I can't do it by using noreturn because my prologue code must be at the 
very top of the function. Same for the epilogue, eg. very bottom.

I could use naked, but then I'd had to make prologued/epilogue for every 
handler by hand. Based on what registers it clobbers. I don't like that 
approach, I will try to make the patch which I described in original post.

Regards!

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