Re: RFC: mips target support for Juniper Apollo

[Jim Wilson <wilson at specifixinc dot com>]

On Wed, 2004-03-10 at 10:11, cgd@broadcom.com wrote:
> actually standard.  I.e., You've solved this problem from a toolchain
> perspective, but not an OS perspective.

I only need a toolchain solution.  This is an embedded processor that
will probably never be used anywhere outside Juniper, so I don't have to
worry about linux ports or anything like that.

> It *really* *really* *really* should have a different E_MACHINE value,
> since it is *fundamentally* incompatible with MIPS.

Everything is MIPS compatible except the delay slots.  True this is a
serious incompatibility, but MIPS16 is also missing delay slots and it
is still part of the MIPS toolchain.  MIPS16 is even more incompatible
with normal MIPS code than Apollo, but it doesn't have its own E_MACHINE
value.  Similarly, 64-bit code is fundamentally incompatible with 32-bit
code, but 64-bit targets don't have their own E_MACHINE value.  I don't
see how sharing the E_MACHINE value is a problem, since Apollo is
clearly in the same family as all other MIPS targets.

MIPS code can run on an Apollo if you fill all delay slots with nops. 
That is what they currently do in the absence of an actual Apollo port.

Giving it a different E_MACHINE value will make the patch bigger and
more intrusive than it needs to be.  I'd would very much prefer to avoid
that.

It is also not clear to me how far you want this to go.  Do I have to
add an apollo-elf configuration?  Do I have to add an
include/elf/apollo.h file?  Is it really appropriate to add, for
instance, bfd_arch_apollo references to MIPS specific files?  This could
potentially end up being a very big patch if I have to duplicate a lot
of MIPS specific code.

>(Whether or not it should ever call itself "mips" in binutils is
>another question, and one that could get fairly ugly.)

I don't know if they have a MIPS license.  I can ask.  Still, I would
expect that if someone contributed a Lexra port that it will still be
merged into the mips port even though they don't have a MIPS license. 
(Or at least they didn't have one initially.)
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com