This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] MIPS/gas: LQC2, LDC3 and SQC2 macro !microMIPS assertions
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Tue, 26 Aug 2014 21:00:24 +0100
- Subject: Re: [PATCH] MIPS/gas: LQC2, LDC3 and SQC2 macro !microMIPS assertions
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 1 dot 10 dot 1408211306030 dot 2958 at tp dot orcam dot me dot uk> <87lhqcz343 dot fsf at googlemail dot com>
On Mon, 25 Aug 2014, Richard Sandiford wrote:
> > This adds missing !microMIPS assertions for the LQC2, LDC3 and SQC2
> > macros whose underlying instructions have no microMIPS encoding.
> I don't really see the need for these kinds of asserts. If the instruction
> isn't available we're going to assert later anyway. The problem with asserting
> here too is that (as this patch proves) it's very hard to maintain the
> consistent duplication of information without some kind of automatic help.
> I'd prefer to go for consistency the other way and remove
> !mips_opts.micromips asserts that are only there because there's no
> underlying microMIPS instruction. This includes the one in the earlier
> SAA(D) patch.
I missed this e-mail from you because unlike the other three it wasn't
delivered to me for some reason, I now only noticed it on the mailing list
(and pulled a copy). So I pushed the SAA(D) patch without seeing your
concern, sorry about that.
I think you're actually right, why didn't I realise that before making
these changes? The thing is these asserts were really needed with the old
INSERT_OPERAND CPP macro that would do something really silly if used for
an unsupported ISA. Now they could have really gone with your removal of
Author: Richard Sandiford <firstname.lastname@example.org>
Date: Sun Jul 14 13:37:51 2013 +0000
however I suppose you didn't want to mess with things more than necessary
with that change and then the issue got forgotten somehow.
So I think I can clean this stuff up easily throughout `macro', though
I'll make some checks first as to what happens if some of these synthetic
instruction macros are indeed inserted into an opcode table of the wrong
Thanks for your feedback.