Re: RFC: mips target support for Juniper Apollo

[cgd at broadcom dot com]

At 10 Mar 2004 13:21:45 -0800, Jim Wilson wrote:
> > 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.

MIPS16 is not a standalone architecture, though, it's an ASE.  it
interoperates/interworks with "normal" MIPS code.

Note also that MIPS16 *does* have its own MIPS ASE flag, i.e., you can
(or should be able to) tell whether a binary uses MIPS16.


> Similarly, 64-bit code is fundamentally incompatible with 32-bit
> code, but 64-bit targets don't have their own E_MACHINE value.

They differ in EF_MIPS_ARCH, though.

Likewise with -- many of -- the other ASEs.  (The place where the
current arch/ase marking falls down is some of the ASEs, and in some
of the FP formats.  But as far as I'm concerned, that's due to lack of
attention.)


In a nutshell, if a program wants to determine if code can run, it
*should* be able to look at a few well-defined fields, incl. E_MACHINE
and EF_MIPS_ARCH and EF_MIPS_ASE, and determine that.

the mips machine stuff is not really the right thing at all in general
(see long-ago discussions on the list -- at minimum: it doesn't
merge), and even if it were reasonable nothing at all checkes it now.


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

It's similar to, but is obviously fundamentally different than, any
existing MIPS architecture.


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

I'd certainly not advocate complete separation.


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

That would get pushback, too, in the same way, as far as i'm concerned.