SPARC Context Switch Code

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Feb 6 14:58:41 UTC 2014


On 2014-02-06 15:33, Gedare Bloom wrote:
> On Thu, Feb 6, 2014 at 7:45 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de>  wrote:
>> >On 2014-02-06 13:17, Ingolf Steinbach wrote:
>>> >>
>>> >>2014-02-06 Sebastian Huber<sebastian.huber at embedded-brains.de>:
>>> >>This switch
>>> >>could happen at arbitrary places (in the interrupted task).
>> >
>> >
>> >Interrupts cannot happen at arbitrary places.  Interrupts can happen when
>> >interrupts are enabled.
>> >
>> >The interrupt prologue and epilogue code must take care about the
>> >interrupted context.  This is done usually in two steps.  The first step is
>> >performed by the processor and the second step is some code that
>> >saves/restores the rest of the volatile context.  This has nothing to do
>> >with the _CPU_Context_switch() function.
>> >
> Sebastian is correct. The callee-save (volatile) registers are saved
> by the ISR handler in case of an interrupt. This is a separate case
> from the context switch code. In case of a dispatch from an ISR, the
> return path from the dispatch (that resumes the interrupted thread)
> will restore the volatile registers.
>
> I think it is safe to remove those registers from the saved context
> state during a context switch.
>
> This issue and others involving context need to be revisited however
> in case thread migrations are allowed. I believe (unverified) thread
> migrations in the sparc can be complex due to the register windows and
> size of the architected state.

Thread migration from one processor to another is not a special case.  The only 
thing you have to ensure is that a thread actually stopped execution before it 
starts on another processor to avoid usage of one stack area multiple times at 
once.

Now back to the SPARC context switch.  The first part of _CPU_Context_switch() 
is quite clear (except the unnecessary save/restore of volatile registers). 
The second part starting with _CPU_Context_restore_heir is a bit tricky.

http://git.rtems.org/rtems/tree/c/src/lib/libbsp/sparc/shared/irq_asm.S#n97

You enter this part with the stack pointer of the currently executing thread. 
Now you save all valid register windows to the stack.  After this operation you 
have exactly one valid window (= the current one).

http://git.rtems.org/rtems/tree/c/src/lib/libbsp/sparc/shared/irq_asm.S#n193

In the last part you restore the context from the context area of the heir 
thread.  This will also switch the stack (in case of a self-restart you destroy 
the window flush operation carried out just before).

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the users mailing list