Re: [ECOS] context switching in ecos

[Nick Garnett <nickg at cygnus dot co dot uk>]

Suet Fei Li <suetfei@bwrc.eecs.berkeley.edu> writes:

> Hi everyone:
> 
> I am trying to understand the context switching stuff in Ecos here.  It
> seems like it goes the following way:
> 
> timer interrupt -> save everything on the current thread stack -> call ISR
> -> Interrupt_end -> call DSP -> lock scheduler -> call
> HAL_THREAD_SWITCH_CONTEXT  -> save current context and load next thread
> context -> return from interrupt -> restore everything.
> 
> It seems to me that the current status of the CPU has to be saved twice
> (once right after the interrupt, the second time during
> HAL_THREAD_SWITCH_CONTEXT ). If this is indeed true, isn't it rather
> inefficient? Why did not it just:
> 
> interrupt -> save everything on the current thread -> scheduler -> load the
> context from next thread.
> 
> Any input will be very very helpful
> 

You have it right there. The main reason for doing it this way is to
avoid the complications of having different kinds of saved thread
state - you often have to save extra state in an interrupt that is not
needed in a straight thread switch. This would also have resulted in
linkage between the thread switch code and the interrupt/exception
handling code. At present they are separate and thus both much
simpler. It makes all the thread switch and scheduler lock code much
more streamlined and sharable because there is no essential difference
between a thread switch as a result of an interrupt and one as a
result of a kernel API call.

The problem of saving the thread state twice can be avoided by only
saving partial CPU states in the two places. This exploits the calling
conventions so that only callee-saved registers are saved in the
thread switch code and only caller-saved registers are saved in the
interrupt code. In the case of an interrupt causing a thread switch,
the whole CPU state is then spread between the two save areas.

Some HALs have support for this, but since it tends to interfere with
debugging, it is not enabled by default.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK