This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SPARCV8 - Context Switch


All messages should be CC's to the ecos-discuss list, that way others
can benefit from the replies.


"Fauze V. Polpeta" <fauze@lisha.ufsc.br> writes:

> Hi Mr. Qiang and Mr Garnett;
> 
> I was searching in the Internet some explanation about the
> switch_context routine of eCos and I found one email of yours where
> you both try to understand such a procedure and how it deals with
> register windows. I perfectly understood your doubt and I think that
> it is a programmer's decision. However I sincerely hope you can help
> on debug the behaviour of the stack under the context switch routine
> because I really cant see where the other windows are stored and,
> indeed, how they are restored when the thread is back.
> 
> Lets supose that we are working with 8 register windows and only the
> windows number 7,6 and 5 (current) are active. That means that the CWP
> points to 5 and the WMI points to the window number 0. The other
> windows are free for using and will be used when we make procedure
> calls and consequently excuting save/restore instructions. At this
> moment, the current thread is stopped and the leaf routine
> switch_context is called. As I could see in the code, firstly it pushs
> the current window (5) onto the stack, reserving for it 4*32 bytes
> (SAVE_REGS_SIZE). The stack looks like that:
> 
> ------- 0x0000
>    ...
> ------- <- sp
>    5    ------- <- previous sp
>    ...
> ------- 0xffff
> 
> Following in order to save the other active windows it executes a set
> of SAVE instructions. Like I could understand, when the other active
> windows are found (the WMI is achieved) the overflow trap handler push
> their registers onto the stack. However even for those windows that
> are not active (4,3,2,1) we saved space on the stack. This is related
> to the doubt of Qiang, and I think that it is a programmer's
> decision. Thus, at this point the stack would looks like follows:
> (please, correct me, if Im wrong)
> 
> ------- 0x0000
>    ...
> ------- <- sp
>    6
> -------
>    7
> -------
> empty
> -------
> empty
> -------
> empty
> -------
> empty
> ------- <- saved place
>    5    ------- <- initial sp
>    ...
> ------- 0xffff
> 
> Here starts my doubt! :)
> As I depicted above, after we push the window 5 to the stack we saved
> the address of the stack pointer and it will be used to restore de
> context later. The restoring routine (the second half of
> switch_context), as I could see, firstly restores the old current
> window (number 5), which is placed at the bottom of the
> stack. Following, it just sets the stack back to its entrant value
> (initial sp) by adding SAVE_REGS_SIZE and returns. But what about the
> other windows? Where the stack point (sp) points now? To the "initial
> sp"? If yes, how the windows 6 and 7 will be restored? I know that
> they will be restored on demand by the thread itself when it executes
> RESTORE routines, but how we know where the other windows are if the
> stack pointer is not pointing (I think) to the right place?
> 
> I sincerely hope that one of you (or the both :) ) could help me. Please!
> 

I'm afraid that my knowledge of the sparc architecture is somewhat
sketchy. The engineer who did the sparc port has moved on and we no
longer have anyone who is up to date on this architecture.

Having said that, clearly the sparc code works, since there are people
out in the community using it.

My understanding of the context switch code is that when a switch
needs to be made, the current thread's register windows are all stored
into their reserved areas in the stack frames they belong to. This is
done by the sequence of save instructions. This fakes a sequence of
forward calls around the window ring. Unused windows will do nothing,
occupied windows will generate a window overflow exception to
store the registers. At the end of this the windows are all empty.

On restore it is only necessary to load the first window, all the
others will be restored using window underflow exceptions as the code
returns up the stack.

I think the information you are missing is that the windows are saved
into pre-existing reserved areas in the stack frames of the functions
they belong to, they are not pushed onto the top of the current stack.

Maybe you need to go and read more of the sparc architecture
documentation, the parts about the calling conventions in particular.

-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts
>>>>> Visit us in booth 2539 at Embedded Systems Conference 2005 <<<<<
>>>>> March 8 - 10, San Francisco http://www.embedded.com/esc/sf <<<<<


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]