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: second post SOS pls. Context switching and loading problem.? for sparc target. Thanks


"Qiang Huang" <jameshq@liverpool.ac.uk> writes:

> Dear Nick:
>    Firstly thank you very much for your email. But maybe I havn't explained
> the question detail and clear enough.
> what I meant in Q1 is that: When HAL_THREAD_LOAD_CONTEXT is called in
> sched.cxx Cyg_Scheduler::start_cpu()  (**NOT drop through from the
> hal_thread_switch_context** then there is no second parameter passed from
> the caller, only the stack pointer of the new thread to be excuted passed as
> parameter to HAL_THREAD_LOAD_CONTEXT) obviously here hal_thread_load_context
> is called without the first part of hal_thread_switch_context being excuted.
> So a series of "save" intructions in hal_thread_load_context could save the
> register windows set (8) onto the stack but the stack point seems to be lost
> after that. (coz the new stack pointer will be loaded in the the stack
> pointer register %o6 in later part of hal_thread_load_context)

If hal_thread_load_context is called directly, then there is no need
to save anything of the current context. This function is defined to
destroy the current context. So it does not matter that we do not save
the %sp, it is never going to be used again.

> 
> In Question 2 what I worry about is that if before context switching the
> last register window context of new thread to be excuted was located in 4th
> register window, if only the last register window is restored back from the
> stack to 4th register window, and also CWP points back to 4th register
> window, 5th, 6th, 7th are not restored from the stack. Then when the new
> thread executes (start from 4th register window) but when it returns to its
> caller and CWP set back to 5th register window, but actually 5th register
> windows has been restored from the stack of the new thread, **WILL THAT
> CAUSE ANY PROBLEM??**
> 
> Do you mean the whole register windows set (8) of the new thread will be
> restored back from the stack of the new thread in hal_thread_load_thread??
> But I just can't figured it out.
> 

What happens is that just one register window is restored, the others
are marked invalid, so when the function returns, it will take a trap
and the trap handler will restore the window for the next
function. This is exactly the same mechanism that deals with
wrap-around in the windows for deep call stacks.

-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/


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


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