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]

Re: SH1 port of eCos


>>>>> "Aaron" == Aaron Passey <aaronp@ngwee.ugcs.caltech.edu> writes:

(thanks, Aaron!)

Aaron> Now to the meat of the issue.  hal/sh/arch/current/src/vector.S
Aaron> seems to contain a lot of SH3 specific assembly which does not
Aaron> apply to the SH1 (or SH2).  It has code in there dealing with
Aaron> the SH3's banked registers which the SH1 and SH2 don't have,
Aaron> for example.  What's the best way to deal with this?  Should
Aaron> all this code get moved to sh[34]/current/src/variant.S?

We don't want to move the functions to the variants. Instead we want
to make some macros that take care of register save/restore. Or
rather, that's the way I'd go - using macros we get the entire program
flow listed in one file, vectors.S.

Presumably the SH1 has some spare registers that can be used in the
early exception handling - otherwise you'd be trashing user code's
state.

So if possible, I suggest rewriting the exception entry functions to
be generic for SH1/SH3/SH4. That is, __exception, __tlb_miss,
and __interrupt. Again assuming the SH1 has these. [if this is not
possible, we can macro'ize that part of the code as well]


Then make the cyg_hal_default_exception_vsr and
cyg_hal_default_interrupt_vsr functions use 

 hal_cpu_save

which the variants provide in the variant.inc file. This macro should
handle everything from entry of those functions to the _vsr_bp_safe
labels.


Same in restore_state, except the code would go in the macro

 hal_cpu_load


On the SH4 we'll eventually get hal_fpu_save/load macros as
well, so entry exit would look something like this:

_vsr:
 hal_cpu_save
 hal_fpu_save sp
_vsr_bp_safe:
 ...
restore_state:
 hal_fpu_load sp
 hal_cpu_load
 rte
  nop


Note that the _cpu_ macros do not take the sp argument since they have
to (depending on config) set up the stack pointer.


If you want to look at some HAL where this has been sort-of-made, see
the MIPS HAL which uses many many macros (but only the fpu macros in
the vsr code).

Think that should do it? Happy with this? Let me know if there are
some things you disagree with - I've never looked at the SH1 and it
may take more magic than the above.



Aaron> Oh, I'm not currently subscribed to eCos-discuss so I would
Aaron> appreciate being cc'd on any replies.

You don't know what you're missing! :)

Jesper

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