RE: [PATCH] gas/opcodes: Add initial arc nps400 support

[Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>]

Hi Andrew,

> So do you see the 'ARC_CPU_DEFAULT' being defined to 'ARC700' for the
> current stock arc binutils, and then set to 'NPS400' for the Mellanox
> NPS400 binutils?

No, more like arc700 or archs. The nps400 is an arc700 with some extra instructions. What I am trying to do is to have a piece of code that is generic and mps400 is only one of the possible configurations. But this discussion may be for another time.
 
> That leaves just a single use of ARC_NPS400 in the opcode library,
> where we include the extension instructions.  One possibility would be
> that I could create a define call ARC_OPCODE_EXTENSION_INSN_FILE or
> some such.  This would be undefined for core arc, and defined to
> "arc-nps400-tbl.h" for nps400, then in arc_opcodes[] we can say:
> 
>     #ifdef ARC_OPCODE_EXTENSION_INSN_FILE
>     #include ARC_OPCODE_EXTENSION_INSN_FILE
>     #endif
> 
> Would that be better?
Looks nice.  You need to think how to test the nsp400 without special actions, if possible.

> > Probably the best will be to make a file common for all other users
> > of ARC architecture which are having their own custom
> > instructions. Hence, I would propose to rename arc-nps400-tbl.h to
> > arc-ext-tbl.h or something of a sort.
> 
> I'm not sure I like that idea.  Keeping different extensions separate
> would be best I think.
> 
> The total number of extensions is likely to be pretty low, but the
> number of entries in (this one at least) is likely to be ~100.
> Keeping them separate will help provide more structure to the code,
> making it more obvious which sets of extensions go together.

I see your point, I just want to avoid to have a separate file for each ARC custom configuration in the binutils (see my generality concern). Again, it is not a show stopper.

 
> >                                                       In this
> > situation, the disassembler may choose the first ones instead of
> > yours. However, in this case, we need to add an option to the
> > disassembler as well.
> 
> If this ever became a problem then I think the correct solution would
> be a new ELF header flag, in the same way we split ARCv2 in to ARCEM
> and ARCHS, we'd split ARC700 into ARC700 and NPS400.  I'm hoping any
> such flag changes can be put off until necessary.

Maybe the best is to have a section with all the relevant information in. However, as you show it, we are not in need of such extra addition to the toolchain.
 
Best,
Claudiu