Re: [ECOS] SH1 port of eCos

[Aaron Passey <aaronp at ngwee dot ugcs dot caltech dot edu>]

Sorry, I was pretty busy this weekend.

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

Yeah, that's certainly one way to do it.  This is actually one of my
biggest complaints about eCos.  There are so many macros everywhere that
it's very difficult to follow program flow.  I realize this is done mostly
for making everything generic and portable but it doesn't make it easy to
read.

There seems to be a reset function, exception handling, TLB miss handling,
an interrupt entry, interrupt stack, boot stack and a few other various
items.  The only thing that looks "cross platform" is complete_startup
which looks like it could mostly be done in C anyway.

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

The problem is that the interrupt/exception structure is significantly
different on the SH1.  First of all, there are 256 vectors, one for each
hardware interrupt and and few for exceptions.  There are no priviledge
levels, no banked registers, no MMU, and no cache.

You have one nice interrupt routine and another exception routine.  I need
potentially 256 copies of this routine.  I could do this with a bunch of
macros and a lot of code duplication (not pretty) or possibly have a macro
that saves a little bit of state, calls another routine to save the rest,
and then jumps to the right ISR.  I have to think about this a little bit
more.

> _vsr:
>  hal_cpu_save
>  hal_fpu_save sp
> _vsr_bp_safe:
>  ...
> restore_state:
>  hal_fpu_load sp
>  hal_cpu_load
>  rte
>   nop
> 
> 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.

I think the exception handling on the two different processors are
sufficiently different that this won't work well.  I think we'll end up
with a pile of ifdefs and almost no common code.  The unfortunate thing is
that SH1 and SH2 are pretty much the same and SH3, SH3e, and SH4 are the
same but the two sets are very different from each other.  Maybe we could
have two files: sh1-2vects.S and sh3-4vects.S under arch/common/src and
avoid a bunch of the ifdefs and a code duplication.  Opinions?

Also, If I make a bunch of changes to vectors.S and the sh3 and sh4
specific files, I won't be able to test them.  Can you try it out on
hardware if I send you a diff?  I'm going to try to come up with something
that looks good in the next couple days I hope people can comment on.

Aaron