MIPS questions

[Patrick Kelsey]

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