RE: [PATCH 1/6] gas/arc: Modify structure used to hold opcodes

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

> > > The problem with this is that as different variations of arc are added,
> > > then it is often more convenient to split instructions apart, so all the
> > > base ADD instructions are together, but, variants of ADD specific to one
> > > variation of arc are grouped with other instructions specific to that
> > > arc variant.  The current data structures don't support this
> > > configuration of instructions.
> >
> > It may not be a good idea to overwrite the basic ARC ISA. Any ARC
> > customer can choose to have a different name than the standard ISA
> > names. Please can u reconsider this.
> 
> I don't really understand what you are suggesting here, but ...
> 
> >                                        I do not see any reason why a
> > customer to use ADD mnemonic and not MYADD or something of a
> > sort.
> 
> ... I think you're saying, change the ISA to work around limitation in
> the assembler :-/ That doesn't feel like a good answer, surely we
> should just adapt the assembler until it is flexible enough to handle
> whatever ISAs we need.

What I am trying to say is that the ADD instruction should be as described in ARC's Programmer Reference Manual, and we shouldn't invent new mnemonics formats. Maybe, you pick wrongly the ADD example, and you don't intend to overwrite the standard ADD mnemonics format, which may break other tools as well (e.g. gcc).
As far as I understand, your patch is about the possibility of describing a 3rd party instruction in separate groups, which is fine by me.

> 
> >       Allowing the overwriting/addnotation of the standard ISA
> > mnemonics is opening a domain of pain.
> 
> Could you clarify who you think will suffer this "domain of pain"?

Mainly, the tool chain maintainer, which needs to keep an eye over the compatibility between the GNU toolchain and the in-house ARC toolchain (we are not alone ;)). 
 
>   1. Keep the current patch series, understanding that the ordering
>   restriction still applies even across disjoint groups of
>   instructions, and accepting that as a know danger area in the
>   assembler.  This would be my preferred solution.

>From my side, the idea of the patch is ok. You need to add the explanation about keeping the ordering even if you use multiple groups somewhere in your patch (probably in tc-arc.c).

Cheers,
Claudiu