This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: SH1 port of eCos
>>>>> "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