public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Richard Sandiford <rdsandiford@googlemail.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: binutils@sourceware.org,  Chao-ying Fu <fu@mips.com>,
	 Catherine Moore <clm@codesourcery.com>,
	 "Joseph S. Myers" <joseph@codesourcery.com>,
	 Daniel Jacobowitz <dan@codesourcery.com>
Subject: Re: [PATCH] MIPS: microMIPS and MCU ASE instruction set support
Date: Sat, 05 Jun 2010 09:17:00 -0000	[thread overview]
Message-ID: <87fx11bzzm.fsf@firetop.home> (raw)
In-Reply-To: <alpine.DEB.1.10.1005302126240.5236@tp.orcam.me.uk> (Maciej	W. Rozycki's message of "Tue, 1 Jun 2010 15:19:24 +0100 (BST)")

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
>  I'll look into whatever's left yet.  Here's the current version for a 
> reference, in case you or anyone else wanted to comment on what I have 
> modified so far (no obligation, of course!).

OK, finally got chance to have a proper read of the changes from
the previous patch, and they look good, thanks.  I'm afraid most
of this is at the level of very minor niggly stuff:

+/* Whether code compression (either of the MIPS16 or the microMIPS ASEs has

s/ASEs has/ASEs) has/

+  if (mips_opts.micromips)
+    return is_micromips_16bit_p (insn->insn_mo)
+         ? 2 : (is_micromips_32bit_p (insn->insn_mo) ? 4 : 6);

This formatting isn't quite right because of the "emacs brackets" rule.
Should be:

    return (is_micromips_16bit_p (insn->insn_mo)
            ? 2 : is_micromips_32bit_p (insn->insn_mo) ? 4 : 6);

or:

    return (is_micromips_16bit_p (insn->insn_mo) ? 2
            : is_micromips_32bit_p (insn->insn_mo) ? 4 : 6);

But I'd be happy with an if-return-if-return-return chain too.
See below about these insns though...

-+  if (!mips_opts.mips16 && !mips_opts.micromips)
++  if (! HAVE_CODE_COMPRESSION)

The GCC decision a few years back was that no space should be added
after a unary operator (as with pointer deference, etc).  Not important
enough to do a sed on the whole source base, but we might as well avoid
changes that go the other way (from no space to space) in GAS.

+static bfd_boolean
+is_size_valid (const struct mips_opcode *mo)
+{
+  gas_assert (mips_opts.micromips);
+
+  if ((micromips_16 || micromips_32) && mo->pinfo == INSN_MACRO)
+    return FALSE;
+  if (micromips_16 && ! is_micromips_16bit_p (mo))
+    return FALSE;
+  if (micromips_32 && ! is_micromips_32bit_p (mo))
+    return FALSE;
+
+  return TRUE;
+}

Hmm, seeing this highlighted more makes me wonder whether
micromips_16 and micromips_32 shouldn't be combined into a
single variable that represents "the size the user set",
with 0 meaning "none".  As it stands, we'll have checks like:

  micromips_16 || micromips_32 || micromips_48

when any future 48-bit support is added.  Having separate variables
also gives the impression that arbitrary combinations are possible.

Also, how about replacing is_micromips_XXbit_p with a function
that just returns the size of a micromips insn?  We generally
deal with byte rather than bit lengths, so both this new function
and the combined "the size the user set" variable should probably
both be byte values.

Seems the code would be a fair bit clearer with those changes,
but maybe I'm wrong...

Maybe the mo->match assertions in is_micromips_XXbit_p are better
done in validate_micromips_insn -- especially if that makes the
changes above easier -- but I don't mind either way.

char
mips_nop_opcode (void)
{
  if (seg_info (now_seg)->tc_segment_info_data.micromips)
    return NOP_OPCODE_MICROMIPS;
 
  return seg_info (now_seg)->tc_segment_info_data.mips16
        ? NOP_OPCODE_MIPS16 : NOP_OPCODE_MIPS;
}

Same "emacs brackets" thing here.  Seems odd to treat microMIPS and MIPS16
differently like this, so I think if-return-if-return-return makes more
sense.

The new mips_handle_align looks very good, thanks.  I'm afraid it's another
silly nitpick, but usual style is not to have the brackets in "*(p++)".

Richard

  parent reply	other threads:[~2010-06-05  9:17 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 18:19 Maciej W. Rozycki
2010-05-23 21:38 ` Richard Sandiford
2010-05-24 22:25   ` Fu, Chao-Ying
2010-05-26 19:47     ` Richard Sandiford
2010-06-01 14:21   ` Maciej W. Rozycki
2010-06-01 14:39     ` Catherine Moore
2010-06-01 22:04     ` Richard Sandiford
2010-06-01 22:47     ` Fu, Chao-Ying
2010-06-05  9:17     ` Richard Sandiford [this message]
2010-07-26 10:56   ` [PATCH] MIPS: microMIPS ASE support Maciej W. Rozycki
2010-07-26 13:25     ` Nathan Froyd
2010-07-26 13:53       ` Maciej W. Rozycki
2010-07-26 19:03     ` Richard Sandiford
2010-12-07  1:13       ` Maciej W. Rozycki
2010-12-12 14:59         ` Richard Sandiford
2010-12-14 13:30           ` Maciej W. Rozycki
2010-12-14 14:51             ` Richard Sandiford
2010-12-16 11:54               ` Maciej W. Rozycki
2010-12-18 10:26                 ` Richard Sandiford
2010-12-14 17:56             ` Joseph S. Myers
2010-12-16 15:28               ` Maciej W. Rozycki
2010-12-17 20:56             ` Fu, Chao-Ying
2010-12-18 10:09               ` Richard Sandiford
2011-01-02 11:36         ` Richard Sandiford
2011-02-21 15:35           ` Maciej W. Rozycki
2011-02-22 20:12             ` Fu, Chao-Ying
2011-02-22 20:19             ` Fu, Chao-Ying
2011-02-24 10:46               ` Maciej W. Rozycki
2011-02-26 11:41                 ` Richard Sandiford
2011-02-28 16:41                   ` Maciej W. Rozycki
2011-02-26  0:00             ` Maciej W. Rozycki
2011-03-13  9:23               ` Richard Sandiford
2011-07-25  7:49                 ` Richard Sandiford
2011-07-26  2:01                   ` Maciej W. Rozycki
2011-07-29  0:58                     ` Maciej W. Rozycki
2011-07-29 11:30                       ` Richard Sandiford
2011-07-29 22:52                         ` Maciej W. Rozycki
2011-02-26 11:36             ` Richard Sandiford
2011-07-26 14:00               ` Maciej W. Rozycki
2010-05-26 20:19 ` [PATCH] MIPS: microMIPS and MCU ASE instruction set support Richard Sandiford
2010-05-27 21:39 ` Richard Sandiford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fx11bzzm.fsf@firetop.home \
    --to=rdsandiford@googlemail.com \
    --cc=binutils@sourceware.org \
    --cc=clm@codesourcery.com \
    --cc=dan@codesourcery.com \
    --cc=fu@mips.com \
    --cc=joseph@codesourcery.com \
    --cc=macro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).