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

>>>>> "Aaron" == Aaron Passey <aaronp@ngwee.ugcs.caltech.edu> writes:

(thanks, Aaron!)

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.

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]


Then make the cyg_hal_default_exception_vsr and
cyg_hal_default_interrupt_vsr functions use 

 hal_cpu_save

which the variants provide in the variant.inc file. This macro should
handle everything from entry of those functions to the _vsr_bp_safe
labels.


Same in restore_state, except the code would go in the macro

 hal_cpu_load


On the SH4 we'll eventually get hal_fpu_save/load macros as
well, so entry exit would look something like this:

_vsr:
 hal_cpu_save
 hal_fpu_save sp
_vsr_bp_safe:
 ...
restore_state:
 hal_fpu_load sp
 hal_cpu_load
 rte
  nop


Note that the _cpu_ macros do not take the sp argument since they have
to (depending on config) set up the stack pointer.


If you want to look at some HAL where this has been sort-of-made, see
the MIPS HAL which uses many many macros (but only the fpu macros in
the vsr code).

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.



Aaron> Oh, I'm not currently subscribed to eCos-discuss so I would
Aaron> appreciate being cc'd on any replies.

You don't know what you're missing! :)

Jesper

  reply	other threads:[~2001-01-12  0:42 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 [this message]
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

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=otbstd6u1w.fsf@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).