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]

stack switching in step (4) (5) (6) for previous question http://sources.redhat.com/ml/ecos-discuss/2002-09/msg00224.html??


Hi nick:
   Thanks for your helpful post.
I just wonder **where** and how are those step (4)-switch to thread stack,
(5)- switch back to thread stack, (6)-switch to interrupt stack implemented
in ecos?

It seems in ecos the only place we can access the stack point(in assembly
code) is vector.S (the place when enter interrupt)and context.S (the place
when switch the context). So When "Request DSR run" (end of
Cyg_RealTimeClock::isr())how can we switch the stack from interrupt stack to
user thread stack(Isn't that should be changed in assembly code?)?

for step (5), before entering the HAL_THREAD_SWITCH_CONTEXT() in
Cyg_Scheduler::unlock_inner() how can we change the stack back to "switch
back to thread stack" without using the assembly code?

Thanks a lot.


First, let's redraw your diagram to closer reflect the truth of how
eCos works:

interrupt VSR
      |
 {disable interrupts}
      |
 save CPU state
      |
 lock scheduler
      |
 switch to interrupt stack
      |
 [enable interrupts](1)
      |
 call ISR ---------|
                   |
              handle device
                   |
            acknowledge interrupt(2)
                   |
             request DSR run
                   |
      |-------------
      |
 switch back to thread stack  (6)
      |
 call interrupt_end() ------|
                            |
                         post DSR
                            |
                        unlock scheduler ----|
                                             |
                                       switch to interrupt stack(4)
                                             |
                                       [enable interrupts](3)
                                             |
                                        call any DSRs
                                             |
                                       [restore interrupt state]
                                             |
                                       switch back to thread stack(5)
                                             |
                            |----------N-new thread?
                            |                Y
                            |                |
                            |           switch context
                            |           {enable interrupts}
                            |                |
                            |           return from switch
                            |           {restore interrupt state}
                            |                |
                            |----------------|
                            |
                      zero scheduler lock
                            |
      |---------------------|
      |
 restore CPU state
 {enable interrupts}


In the above diagram, the actions in square brackets indicate optional
manipulations of the interrupt state. The actions in curly brackets
are implicit changes of state caused by the hardware or restoring a
saved PSR or equivalent.

If the interrupt enable at (1) is present, then the enable at (3) is
not strictly necessary, although it is harmless. If (1) is not present
then (3) causes all DSRs to be run with interrupts enabled. Since the
execution time of DSRs is non-deterministic it is important that they
run with interrupts enabled. Similarly, since their stack usage is
unknown, the stack switches at (4) and (5) help to reduce thread stack
usage. The entire sequence between (4) and (5) is a HAL implementation
option.

Whether it is possible to add the interrupt disable at (1) depends a
lot on the architecture and the interrupt controller. In particular,
how a pending unacknowledged interrupt is handled. If the hardware
behaves sensibly, then with the enable at (1), fresh interrupts will
only be permitted when the current interrupt is acknowledged at (2).
Poorly behaving hardware would cause an immediate re-interrupt at (1).

For simplicity, some HALs have not implemented the additional enable
at (1), but do implement the DSR sequence between (4) and (5). This
helps to reduce the interrupt latency without the added complication
of handling, and debugging, nested interrupts.



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