This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: amount of cpu state to be saved for exceptions
- From: John Newlin <jnewlin at gmail dot com>
- To: sandeep <shimple0 at yahoo dot com>, ecos-discuss at ecos dot sourceware dot org
- Date: Mon, 13 Dec 2004 18:04:53 -0800
- Subject: Re: [ECOS] amount of cpu state to be saved for exceptions
- References: <41BB1C0F.4060606@yahoo.com> <41BD64DC.2030300@yahoo.com>
- Reply-to: John Newlin <jnewlin at gmail dot com>
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