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: why need to call Cyg_Scheduler::get_current_thread()->set_saved_context(regs) in interrupt_end()?


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

> Hi Nick:
>    Thanks for your help. What I mean is: in interrupt_end() a call to
> Cyg_Scheduler:: (1) get_current_thread()->set_saved_context(regs) will be
> made and later on (2) Cyg_Scheduler::unlock() will be called (which will
> call into unlock_inner() then hal_thread_context_switch() will be called).
> So in step (1) the "regs"  is passed from the assembly code (eg. for sparc ,
> in vec_ivsr.S), so before entering interrupt_end() "regs" should have been
> already saved, Is "regs" the context before entering the
> interrupt?(interrupted thread's context?), if so in step(2) when executing
> the hal_thread_context_switch() the context of the old thread(the
> interrupted thread's context) will be saved and new thread's context will be
> switched in, then is that means the old thread's context(interrupted
> thread's context) will be saved twice?
> 

Ignore set_saved_context(), it is for debugging only and has no effect
on the state of anything else.

The context saved in the interrupt VSR is that of the interrupted
code. The context saved in hal_thread_context_switch() is that of
where it is called from.

We have options in some HALs to control exactly which registers get
saved in an interrupt and which get saved in a context switch. When
these are enabled only caller-saved registers are saved in the
interrupt and only callee-saved registers are saved in the context
switch. Hence the entire CPU state of an interrupted thread is
actually distributed across two save areas, and very little is
duplicated.

Some HALs do not implement these options since the actual savings are
minimal for some architectures (x86) or because the implementor
couldn't be bothered (MIPS).

-- 
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]