public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Aaron Passey <aaronp@ngwee.ugcs.caltech.edu>
To: Jesper Skov <jskov@redhat.com>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] SH1 port of eCos
Date: Mon, 15 Jan 2001 15:49:00 -0000	[thread overview]
Message-ID: <20010115234901.E4E05CC001@ngwee.ugcs.caltech.edu> (raw)
In-Reply-To: <otbstd6u1w.fsf@thinktwice.zoftcorp.dk>

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

  reply	other threads:[~2001-01-15 15:49 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 [this message]
2001-01-15 18:40     ` Jonathan Larmour
2001-01-15 20:10       ` Aaron Passey
2001-01-15 23:55     ` Jesper Skov

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=20010115234901.E4E05CC001@ngwee.ugcs.caltech.edu \
    --to=aaronp@ngwee.ugcs.caltech.edu \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=jskov@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).