SH Question

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> 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)

Hmm.. I was leaning against this thinking there was more likelihood
of variation in peripherals than in the core CPU functions. Refer to
http://www.hitachi.co.jp/Sicd/English/Products/micome.htm where it 
says there are six kinds of CPU core (SH-1, SH-2, SH2-DSP, SH-3,
SH3-DSP, SH-4).  As a worst case, this means there are only 6 possible
versions of the context switch code.  There appear to be on the order
of about 30 specific CPU models.  So having CPU core based directories
with the context switch and (possibly) interrupt dispatching code
seems very desirable and doable.  

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

I was not necessarily trying to compress all context switch code
down to a single implementation.  Only make it possible to have 
all sh2 models (I count 17) use the same code.  For now, if the sh2 
uses the sh1 context switch code, then that is possible but not
a requirement.

> * 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.

OK.  But should every SH model have to duplicate all the code?
I just want to make sure the organization allows sharing is 
more possible.  
 
> > 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 suspected as much.  I was proposing to break it out in its own file.

> > 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.

If you ignore shared, what is wrong with sh1/sh2?  As I pointed out
above,
there are 17 sh2 cpu models -- why shouldn't it be easy for them to
share
code?
 
> > I would also think that the /dev/null driver could be moved to a
> > non-SH directory.
> 
> <sigh>
> .. finally :)
> </sigh>

This one is moving. :)  I your opinion, does the stub driver serve any
useful purpose other than as a test fixture?

> > 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985