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: amount of cpu state to be saved for exceptions


On Mon, 13 Dec 2004 15:16:04 +0530, sandeep <shimple0@yahoo.com> wrote:
> > in __default_exception_handler, cyg_hal_exception_handler is passed the
> > address of saved CPU state.
> >
> > since we don't know, in what way application installed handler would
> > want to make use of saved state (it might choose to look at some/all of
> > the saved cpu state), we can't drop any savings even for production
> > kernel, where for speedups we could drop saving callee-saved registers
> > in case of interrupts.
> 
> Is above right?
> 
> There is another related doubt that i have is -
> 
> is it necessary to use same HAL_SavedRegisters structure for interrupts,
> exceptions and context switch? could you have variations of same structure
> definition to be used with each of them?
> 
> following issues are responsible for above question.
> 
> the architecture i have worked upon has some facility to save/restore two
> registers at a time, but that requires save/restore address 64 bit aligned.
> again
> - during context saving only callee saved registers and minor housekeeping
> information are saved (<50 bytes)

Let's say you have 8 registers.  1-4 are callee saved, and 5-8 are
caller saved.  During normal execution, the caller will save 5-8, make
the call, and on return, restore 5-8.  If needed of course.  However,
when an interrupt occurs, one of those registers (5-8) may be in use. 
If you were only to allow context switches when the program is on a
call instruction it would work though.

I probably misunderstood what you are trying to do though.  :)

-john

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


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