Stack - OS and Application

What an OS does with stacks depends on the OS. It's pretty much necessary to maintain a stack for each thread of execution, so you can count on that happening. Some of the really small microkernels (Micro-C/OS for example) don't really maintain an independent thread other than the idle thread; other OS's (like Linux or Windows) may have many applications and drivers, each with their own tasks, running in the background.

In article , karthikbalaguru writes: |> |> Does the OS have separate stack area for itself(operating system) and |> separate stack area for the application ? |> Or |> Does the stack area of the application will be part of the |> stack(bigger stack) of the Operating System ?

Either, both or neither, depending. I have seen all of those.

|> I do not find Clear information w.r.t this on the internet. Any |> ideas ? |> Can somone tell me w.r.t a specific OS & application ?

Look, you are likely to get confused if you proceed like this, and will certainly annoy people.

I recommend finding a book that gives an introduction to operating system design, and reading it. Ask on comp.theory for book recommendations.

And don't post basic questions to so many groups.

Regards, Nick Maclaren.

In our proprietary RTOS HALOS, I also maintain a separate stack for all of the interrupt system. Thus the nested interrupts do not waste the stack space of the tasks; also the interrupt stack is located in the fast memory area, so the response time is better.

If you have a full blown MMU and non-RTOS desktop OS, this is a different story.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Any particular OS you are thinking of?

See

You can do this with Micro-C/OS-II as well, although you have to add it in yourself. It's a good thing if you have a lot of tasks in a memory-constrained system: instead of having to add space for the interrupts everywhere, you only need it in one spot.

Even with an MMU a separate thread needs its own stack space. Its existence may be buried underneath a pile of other code, but it'll still be there.

Depending on how you define a thread, I would add "*in a pre-emptive system* - a separate thread needs its own stack space". Cooperative threads can share a stack. FreeRTOS.org has both.

In article , "FreeRTOS.org" writes: |> |> > Even with an MMU a separate thread needs its own stack space. Its |> > existence may be buried underneath a pile of other code, but it'll still |> > be there. |> |> Depending on how you define a thread, I would add "*in a pre-emptive |> system* - a separate thread needs its own stack space". Cooperative threads |> can share a stack. FreeRTOS.org has both.

Commonly called coroutines. And they can all share space if they use the heap to get each frame, preemptively or not. And you can have threads that have no associated storage. And ....

Regards, Nick Maclaren.

Just another illustration that mucos is a toy and its architecture is miserable.

Another advantage is that the interrupt stack is located in the fast memory on chip, so the interrupt latency is low and independent of the state of the cache and the timing of the bus.

The MMU is the good thing to have. It solves so many problems. Even a

Vladimir Vassilevsky DSP and Mixed Signal Consultant

Ditto....Do your own homework....Cheating is not allowed...

-J