Helppppp on Context Switching.

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.