This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


* Claudiu Zissulescu <Claudiu.Zissulescu@synopsys.com> [2016-04-04 14:43:15 +0000]:

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

I think you're covering a lot of ground here, some of which I agree
(strongly) with you on, but I don't think are what I'm proposing.

Let's consider ARC700 for now, it has a specific set of ADD
instructions defined.

Now I'm _adding_ extension instructions.  If one of my extensions
instructions happened to be an addition instruction that took 4
registers, such that DST = SRC1 + SRC2 + SRC3, then this is clearly
_not_ part of the core ARC700 architecture, but could live quite
happily as an extension to ARC700.

If I wanted to make an extension to ARC700 that actually rendered some
of the core ARC700 instruction formats invalid, or gave them a
different encoding then (a) I agree that's probably a bad idea, and
(b) I would argue that stops being an extension to ARC700, and becomes
a new architecture variant that is similar too, but is _not_ an
extension of ARC700.

What I want to do here is make an extension.  Unless I teach GCC about
the new instructions then GCC will never use them, but neither will
anything produced by GCC fail to assemble, all the core instructions
are still valid.

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

Sure, but I suspect you guys will not be rushing to add nps support to
your in house tools.  If I (or anyone else) puts forward a patch that
changes core arc700 functionality then that patch is broken.  If the
patch makes it into master then it needs fixing / reverting and more
tests adding.

As all these new instructions are extensions there should be no risk
of compatibility problems.  Of course we need to be careful in review,
but that's always true :)

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

OK, that sounds like you're basically happy with the patch as is
then.  I'll update the patch series and post a new version here real
soon.

In the end I placed the comment into opcodes/arc-opc.c, at the head of
the arc_opcodes table.  I figured that anyone interested in adding new
instructions would go there first, and any comment there was most
likely to be found / read.

I look forward to any further feedback you have.

Thanks,
Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]