From: Jesper Skov <jskov@redhat.com>
To: Aaron Passey <aaronp@ngwee.ugcs.caltech.edu>
Cc: Jesper Skov <jskov@redhat.com>, ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] SH1 port of eCos
Date: Mon, 15 Jan 2001 23:55:00 -0000 [thread overview]
Message-ID: <14947.65102.995357.51847@thinktwice.zoftcorp.dk> (raw)
In-Reply-To: <20010115234901.E4E05CC001@ngwee.ugcs.caltech.edu>
>>>>> "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
prev parent reply other threads:[~2001-01-15 23:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-11 13:02 Aaron Passey
2001-01-12 0:42 ` Jesper Skov
2001-01-15 15:49 ` Aaron Passey
2001-01-15 18:40 ` Jonathan Larmour
2001-01-15 20:10 ` Aaron Passey
2001-01-15 23:55 ` Jesper Skov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14947.65102.995357.51847@thinktwice.zoftcorp.dk \
--to=jskov@redhat.com \
--cc=aaronp@ngwee.ugcs.caltech.edu \
--cc=ecos-discuss@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).