MIPS questions

[Joel Sherrill]

Ralf... I know you have some thoughts on this.  The mips
targets in the GNU tools have multiple configure tuples 
(tx39, mips64orion, mips, etc) that all map to "config/mips".  
I have a feeling we may be having to do that also.

There has been some work over the past few months by Alan Cudmore
and others to make the mips64orion port more universally useable
on all the mips variants.  In doing so, I made the (hard) decision
to obsolete the mips64orion port but leave it in place until
the new mips target was proven to be a suitable replacement.  The
idea is that the "mips-rtems" target is suitable for use on any
mips variants.  I would HIGHLY recommend (read beg) that you look at
score/cpu/mips and see if it can or be made to work for your RC32300.  

Your comment that is a "mutt isa" scares me a bit since the code
needs a way from the toolset to know what instructions are valid
to use.  With such an oddball combination, this does not seem to
map cleanly on the multilib variants available with normal mips
targets.  Is this right?

Regardless the score/mips code is intended to have broken out
pieces of code based on gcc cpp predefines.  All you have done is
add another combination.

If necessary, we can go to the GNU tools mips solution which is
to have various mips configure tuples but only one real set of mips
target code.  Ralf surely has an opinion and a way to solve this here.
:)

The ultimate goal from my perspective is to have ONE set of score/mips
code that uses predefines from gcc to know what instructions it
is allowed to use.  It may ended up used as the basis for 
multiple mips tuples.  libcpu/mips can decide based on RTEMS_CPU_MODEL
and
make appropriate decisions.  

But to do the "ONE score/mips" path, the tools MUST always be honest
about what cpu model features are available -- soft float, ISA level,
etc, etc. in a way that RTEMS can trust.  The "normal" C code will
take care of itself but the RTEMS CPU dependent code must be told
what to do.

--joel

Patrick Kelsey wrote:
> 
> Hello,
> 
>     We use two mips variants - 64-bit orion processors such as the R4700 and
> a 32-bit processor based on IDT's RC32300 (a 32-bit mips core with no fpu
> and a mutt isa: mips2 + non-64-bit mips4 + a few special insns like mad,
> msub, etc.).  The orion processors are supported directly by the mips64orion
> targets in the gnu tools and in RTEMS.  To support the 32300-based processor
> under RTEMS, we added minor patches to the mips64orion cpu-specific files in
> the distribution.  Originally we used a hacked version of the mips64orion
> gnu tools, but we are moving to a separate gcc/binutils/newlib target that
> we have created for the 32300 to circumvent some fundamental problems with
> the former approach.  So now we have two sets of tools built -
> mips64orion-rtems-gcc et. al and mips32300-rtems-gcc et. al, with their
> corresponding newlibs.  The question is what is the best way to add support
> for building RTEMS with the mips32300 toolset?  The idea is that I would be
> able to run either of these two commands:
> 
> bit_rtems mips64orion some_bsp
> bit_rtems mips32300 some_other_bsp
> 
> and the configure process would select the appropriate toolset
> (mips64orion-rtems-* or mips32300-rtems-*) and the appropriate cpu-specific
> subdirs.  Currently, it seems that the name of the cpu-specifc subdir has to
> be the same as the cpu name used to form the toolset prefix.  Perhaps there
> should be separate ways to specify the cpu-specifc subdir name and the tool
> prefix to accomodate situations like this.  Or am I missing something?
> 
> Thanks.
> 
> P.S. It is our intention to make the 32300 patches available once we have
> all of this sorted out.  The patches should support IDT's  'RC32334 and
> 'RC32364, although we only use the 'RC32364.
> 
> --
> Patrick Kelsey
> 
> Woodward McCoach, Inc.        (voice) 877.284.4804 x126
> pjk at wmi.com                            (fax) 610.436.8258

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