This is the mail archive of the ecos-discuss@sourceware.cygnus.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]

Re: PowerPC HAL questions.


Sergei Organov <osv@javad.ru> writes:

> Nick Garnett <nickg@cygnus.co.uk> writes:
> > Sergei Organov <osv@javad.ru> writes:

> Now when FP switch "on demand" is configured, I still need to call DSRs
> through the HAL even if CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK is
> disabled. From your explanation I now understand that I better don't enable
> interrupts in this case before entering DSR, right?

That is correct. 

> 
> [...]
> > > Q.6. The common level-0 code of VSRs uses SPRG1-3 to save work registers, then
> > > the SPRG1-3 are moved back to GPRs and are stored on the stack by the default
> > > VSRs. Isn't it better to store work registers directly on the stack and use
> > > SPRGs for some global variables such as address of 'hal_interrupt_handlers',
> > > address of 'hal_interrupt_data', etc.? It will also allow to save SRR0 and
> > > SRR1, and then set MSR RI as soon as possible. This could be critical for some
> > > applications (e.g., MPC509 goes to the check-stop state if another exception
> > > occurs when RI bit isn't set, processor hangs, and even internal watchdog
> > > doesn't work. The exception could occur due to spikes on the bus while testing 
> > > by applying high voltage to the ground of the device).
> > > 
> > 
> > There are several reasons for the code being as it is. The first is to
> > make the exception decode code in the exception_vector macro as fast
> > as possible by not touching memory more than the once to get the VSR
> > table entry. We cannot assume that the SP is necessarily valid at this
> > point. Although the default VSRs make this assumption, VSRs for
> > handling things like TLB miss should not.
> 
> Do you mean that eCos will support virtual memory in the future? Or there are
> some other reasons to handle TLB misses? Are there other possible cases when
> SP could be invalid? Anyway, it could be handled by providing special level-0
> code for given exception vector in the HAL.

We probably will not support virtual memory, but there are often
reasons for running the MMU, like cache control, remapping IO memory
space etc. Things like memory allocators and garbage collectors may
also want to make use of MMU features, and may want to install their
own TLB miss VSR.

> 
> > If we stashed some data on the stack in this macro, it is very possible that
> > the default VSRs would have to pop it again to set up their own saved
> > states.
> 
> This seems to be questionable. At least when I wrote "FP unavailable"
> VSR, I was forced to save a few registers on the stack anyway, and if VSR
> entry code did it for me, I definitely don't pop them back until the end of
> the VSR. For me it seems best if level-0 code creates the standard
> exception/interrupt stack frame and stores working registers at the standard 
> places in the frame. Why then default VSRs need to pop them back?

If we made the standard interrupt frame, we would be making more
assumptions about the stack and the availability of memory below
it. This is not something I am happy for the level-0 code to do.


> 
> > We also want to provide the option of fast interrupt and exception handling
> > to applications by allowing them to install their own VSRs. We do this by
> > entering the VSR with the minimum of change to the machine state that
> > we can achieve.
> 
> Well, that's a good thing. But unfortunately it creates an overhead in all
> existing VSRs in favor of optimizing for some (imaginary ?) cases. Note that
> after level-0 code there are only 2 somewhat free working registers (LR and
> R3), and thus almost any reasonable VSR will need to store something on stack
> anyway ;-) Both default VSRs and those one I wrote for "FP unavailable" VSR
> make this fairly obvious for me. 

The current code gives us minimum latency between the exception being
delivered and entry into the VSR. As you say, few VSRs will not save
extra registers to memory, but how they do that, and where, is their
business. Some might save to a static area, others might only push a
handful onto the stack. I didn't want the level-0 code to make any
premature choices of this sort, hence the effort to keep everything in
registers.



-- 
Nick Garnett
Cygnus Solutions, a Red Hat Company
Cambridge, UK


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