Forums

Helppppp on Context Switching.

Started by #define December 12, 2005
Hello,

I have one basic doubt about how context switching work in RTOS.

Where does the RTOS saves the PC (Program Counter). Is it on the stack
of the thread (Then how PC is pushed (i guess only CALL instruction has
that power), or can PC be treated as any other register especially in
32bit RISC uC and pushed on stack)?

Then, how does the contents of PC  changed by RTOS once it is done
restoring (popping) registers etc.
again there is no such thing as POP PC !!!! (RET and JMP A+@DPTR come
to mind)

Anybody????? Helppppp me.

Regards,

#define

On 2005-12-12, #define <u4karsh@gmail.com> wrote:

> Where does the RTOS saves the PC (Program Counter). Is it on the stack > of the thread
Usually.
> (Then how PC is pushed (i guess only CALL instruction has that > power),
Most RTOSes (at least the ones I've seen the insides of) do their context switching from an interrupt service routine, so the processors interrupt mechanism does the "push".
> or can PC be treated as any other register especially in 32bit > RISC uC and pushed on stack)?
Depends on the processor. Sometimes it can.
> Then, how does the contents of PC changed by RTOS once it is > done restoring (popping) registers etc. again there is no such > thing as POP PC !!!!
Depends on the processor. Sometimes there is.
> (RET and JMP A+@DPTR come to mind)
Usually you switch the stack pointer over to point to the stack of the new thread and then do a "return from interrupt". -- Grant Edwards grante Yow! I HAVE a towel. at visi.com
Let's say "some" event has happened and a HIGHER priority is READY.

Now a Lower priority thread (in middle of its time slice) will still
not be able to continue. (Thats what shoud happen right!)

Now no there is tick interrupt...still context is switched...How?

Regards,

#define

> Where does the RTOS saves the PC (Program Counter). Is it on the stack > of the thread (Then how PC is pushed (i guess only CALL instruction has > that power), or can PC be treated as any other register especially in > 32bit RISC uC and pushed on stack)?
This depends on the processor architecture, but it is normal for the PC to automatically get stored on the stack when context switching - just as with any other function (or interrupt) call. Entering the function with a branch instruction will normally automatically store the PC + offset as the return address on the stack. Exiting the function with some form or return instruction will normally automatically retrieve the return address from the stack and load it into the PC. Take a look at the second section of http://www.freertos.org/implementation/. There is a detailed example. Regards, Richard. http://www.FreeRTOS.org
On 2005-12-12, #define <u4karsh@gmail.com> wrote:

> Let's say "some" event has happened and a HIGHER priority is > READY.
OK, buth there's no need to SHOUT. ;)
> Now a Lower priority thread (in middle of its time slice)
RTOSes don't usually use time-slices. A few have time-slicing as an optional feature, but it's often considered "bad practice" to resort to time slicing.
> will still not be able to continue. (Thats what shoud happen > right!)
Right.
> Now no there is tick interrupt... still context is switched... > How?
1) In many (most, in my experience) cases the event that made the higher priority task runnable was caused by an interrupt (e.g. I/O device or hardware timer). In that case, the context switch is done at the end of the ISR. 2) If a context switch really does need to be trigger from a user task, all of the processors I've ever used have a software interrupt mechanism. -- Grant Edwards grante Yow! YOU PICKED KARL at MALDEN'S NOSE!! visi.com
Grant Edwards wrote:
> On 2005-12-12, #define <u4karsh@gmail.com> wrote:
>>Now no there is tick interrupt... still context is switched... >>How? > > > 1) In many (most, in my experience) cases the event that made > the higher priority task runnable was caused by an interrupt > (e.g. I/O device or hardware timer). In that case, the > context switch is done at the end of the ISR.
Yes. To expand a little bit, usually when servicing an interrupt, you execute common interrupt entry and exit code. This would typically track the number of nested interrupts. When the exit routine determines that it is ready to return to task (non-interrupt) code, it checks to see if the suspended task is still active (normally a flag). If so, it simply returns to it. Otherwise, it would save the context of the current task and restore the context of the newly activated task and start it. -- Thad
"Grant Edwards" <grante@visi.com> schreef in bericht 
news:11prm11anj8k82c@corp.supernews.com...
> On 2005-12-12, #define <u4karsh@gmail.com> wrote: > >> Now no there is tick interrupt... still context is switched... >> How? > > 1) In many (most, in my experience) cases the event that made > the higher priority task runnable was caused by an interrupt > (e.g. I/O device or hardware timer). In that case, the > context switch is done at the end of the ISR.
Unless the OS uses interrupt processes, in which case the context switch is done at the beginning of the ISR. And again at the end.