[ECOS] SH1 port of eCos

[Jesper Skov]

>>>>> "Aaron" == Aaron Passey <aaronp@ngwee.ugcs.caltech.edu> writes:
Aaron> Yeah, that's certainly one way to do it.  This is actually one
Aaron> of my biggest complaints about eCos.  There are so many macros
Aaron> everywhere that it's very difficult to follow program flow.  I
Aaron> realize this is done mostly for making everything generic and
Aaron> portable but it doesn't make it easy to read.

Agree. Makes the learning curve steeper - but it makes for easier
maintainment. And we obviously prefer the latter over the former.

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

The reason it looks the way it does is because it was written for the
SH3. 

But it's no problem to move the exception/interrupt entry points into
the variant HALs. default_vsr handlers should remain in the main code,
but rely on macros for saving away registers as suggested before.

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

Other than the above, I don't see anything but possibly the
CYGARC_SH_SOFTWARE_IP_UPDATE code which needs to be macro'ized.

Yes, this does reduce vectors.S to basically user level ABI code -
which is fine. I don't want two files with the same ABI code.

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

Sure.

Jesper