SH Question

[Ralf Corsepius]

Joel Sherrill wrote:
> 
> I am trying to reduce the duplication between sh7032 and sh7045 in the
> libcpu code.  In particular, I believe it should be possible to have
> a single copy of the context switch and interrupt dispatching code.
Well ... I am not very fond of this.

Though the SH7032 and SH7045 are very similar, they actually are
members of two different cpu families (SH1 and SH2), which by
accident (In fact Hitachi's learning curve) are _very_ similar but
not identical.

In addition, the observation that many portions of their sources are
identical or at least very similar, is more or less sheer random
luck and primarily result of these RTEMS-ports' history: The
SH7045/SH2 port actually is a copy of the SH7032/SH1 port with minor
adaptations to the SH7045/SH2 and no real optimisations applied.

I.e. 
* yes, some portions of the duplicated code could be shared among
different SH-variants (esp. on-CPU peripherials' device drivers)

* others can not or only with applying hacks (cascades of defines
fall into this category, IMO).

* The current state of the SH2/sh7045 code should be considered to
be designed and designated to be optimized, adapted and improved to
the SH2. As the SH1 and SH2 are _very_ similar, this in many cases
means using duplicate code. With other SH variants (> SH2) however,
this definitely will diverge.

> But I have run into a routine that I can't figure out how portable
> it really is .. so how portable is the routine
> sh_set_irq_priority()?
Dunno, either - But I don't think it is portable across the
SH-variants.

> I am leaning toward creating "shared", "sh1", and "sh2" subdirectories.
I vote against this. The current implementation is simple, clean,
straight and easy to modify if _needed_. I do not think attempting
to share _this_ code is worth the effort. Moving the files into
shared, sh1 and sh2 subdirectories would spoil this simple structure
and would add (unnecessary) complexity for the sake of (IMO)
marginal benefits resulting from code sharing.

> I would also think that the /dev/null driver could be moved to a
> non-SH directory.

<sigh>
.. finally :)
</sigh>
 
> Comments, suggestions?

Cf. above.

Ralf.

-- 
Ralf Corsepius 
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999  
http://www.faw.uni-ulm.de