This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] MIPS: Opcode membership proposal
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Alan Modra <amodra at gmail dot com>, <binutils at sourceware dot org>
- Date: Mon, 17 Jun 2013 23:30:14 +0100
- Subject: Re: [PATCH] MIPS: Opcode membership proposal
- References: <alpine dot DEB dot 1 dot 10 dot 1012181108290 dot 4142 at tp dot orcam dot me dot uk> <alpine dot DEB dot 1 dot 10 dot 1110311233290 dot 28657 at tp dot orcam dot me dot uk> <87obway4f5 dot fsf at firetop dot home> <alpine dot DEB dot 1 dot 10 dot 1208092012040 dot 20608 at tp dot orcam dot me dot uk> <20130617115141 dot GU21523 at bubble dot grove dot modra dot org> <alpine dot DEB dot 1 dot 10 dot 1306171606330 dot 16287 at tp dot orcam dot me dot uk> <87y5a8o6oj dot fsf at talisman dot default>
On Mon, 17 Jun 2013, Richard Sandiford wrote:
> > This looks a bit convoluted, and frankly I'd prefer if automake supported
> > true per-object flags with no need to resort to hacks like this, but there
> > you go. The benefit would be no need to check the rules against generated
> > ones with each automake upgrade, that is less maintenance burden -- and
> > the maintenance of our autoconf scriptery has already proved tough even
> > without that.
> >
> > Do you want me to check this alternative or would you prefer to do this
> > yourself?
>
> What do you think about explicitly initialising each field after all?
> I can easily repurpose the ASE-checking script to do that.
Great! I'm fine with that, sure. While at it we could add pinfo3 too --
some microMIPS instructions (offhand: ALNV.PS ;) ) will benefit from more
accurate data dependency tracking.
> I understand the original reason for having optional fields, but the
> workaround is beginning to feel a bit convoluted. There's also more
> room for confusion than there was originally, now that we have the
> ASE field too.
Agreed. What I think was important was not to add an extra field while
rewriting the opcode table at the same time -- that would obfuscate the
change itself.
Maciej