Re: [PATCH] Add .set arch=FOO support to MIPS gas.

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

cgd@broadcom.com wrote:
[snip]
> personally, i think i'd actually stuff the 'mipsN' and 'arch=' into
> the same outer 'if' check  (i.e., look for arch= and mips*, then do
> the right thing for each inside).

But they are semantically different. arch= changes the ISA, but
mipsX does not change the architecture.

> If you don't do that and don't otherwise share the switch stmt (hey,
> I'm OK w/ goto... 8-), i'd advise copying the other one verbatim and
> making comments in both places.
> 
> (Well, I suppose there might be a reason to do the above based on arch
> rather than ISA, but I can't figure it.  Do you have some reason to
> not do it exactly the same?)

If there's a 64bit capable CPU which does not support MIPS III but say
lacks some of the MIPS II insns we need to base this on arch.

There _are_ 64bit CPUs without ll/sc, from a vendor which shall remain
unnamed. ATM, we just ignore the problem and assemble those insns
happily for them.

> combining them into the same option makes the code a bit deeper, but
> the 'weird' part is the switch statement above, so best to keep that
> in one place IMO.  Plus, leads to less maintenance long term if there
> are more 32-bit core variants.
>
> Hmm, completely unrelated, but looking to see if you got all of the
> 32-bit arches:
> 
>   { "r4010",          0,      ISA_MIPS2,      CPU_R4010 },
> 
> in the MIPS III section of the table.  This appears to be an LSI
> R4010, rather than the R4010 which seems to be the name for the
> R4000/R4400 FP coprocessor.  8-S
>
> anybody know what the right thing is there?  The disassembler says
> that it's:
> 
>   { "r4010",    1, bfd_mach_mips4010, CPU_R4010, ISA_MIPS2,
>     mips_cp0_names_numeric, NULL, 0, mips_hwr_names_numeric },
> 
> So, I think you missed this one (and it illustrates why IMO it's
> better to do the switch by ISA 8-).

Well, mips-opc.c says

  /* Conflicts with the 4650's "mul" instruction.  Nobody's using the
     4010 any more, so move this insn out of the way.  If the object
     format gave us more info, we could do this right.  */
  {"addciu",  "t,r,j",    0x70000000, 0xfc000000, WR_t|RD_s,    L1  },

and the 4010 specific opcodes seem not to be for 64bit, so I guess
it is really an obsolete 32bit chip. But bfd disagrees in cpu-mips.c:

  N (64, 64, bfd_mach_mips4010, "mips:4010",      FALSE, NN(I_mips4010)),


Thiemo