public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Jan Beulich <jbeulich@suse.com>
Cc: Binutils <binutils@sourceware.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	 Andrew Waterman <andrew@sifive.com>,
	Jim Wilson <jim.wilson.gcc@gmail.com>,
	 Nelson Chu <nelson@rivosinc.com>
Subject: Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
Date: Sun, 15 Jan 2023 04:35:22 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2301150420040.50462@angie.orcam.me.uk> (raw)
In-Reply-To: <95936261-d824-9128-1be9-ba7dfe12b042@suse.com>

On Fri, 13 Jan 2023, Jan Beulich via Binutils wrote:

> While not spelled out by the spec, gas has been supporting these aliases
> virtually forever. Yet they were unused by the disassembler because of
> sitting later in the table. Move the non-aliases down.

 I think this is going backwards.  Aliases are used in disassembly to 
improve readability, e.g. to show `nop', rather than `c.addi zero,0' which 
would make anyone scratch their head, at least initially.

 In this case there's no improvement, but obfuscation, as you're losing 
the clear distinction between the register and the immediate instructions 
and one will have to examine the operands to spot the difference.

 The alternative mnemonic forms for immediate machine instructions are 
there (NB pinched from the MIPS assembly dialect) to make it easier for 
people to write handcoded assembly, especially where macros are involved, 
either GAS or C preprocessor ones, and not for disassembly.  Conceptually 
they're assembly macros that expand to a single instruction rather than 
aliases.  IOW it's not a bug that those are not considered aliases for 
disassembly.

 Likewise with the remaining patches in this series.

  Maciej

  reply	other threads:[~2023-01-15  4:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 10:18 [PATCH 0/3] RISC-V: further alias insn handling adjustments Jan Beulich
2023-01-13 10:19 ` [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U} Jan Beulich
2023-01-15  4:35   ` Maciej W. Rozycki [this message]
2023-01-16  7:46     ` Jan Beulich
2023-01-25  0:42       ` Maciej W. Rozycki
2023-01-25 15:02         ` Jan Beulich
2023-01-25 15:22           ` Maciej W. Rozycki
2023-01-26  1:29             ` Andrew Waterman
2023-01-26  9:35               ` Jan Beulich
2023-01-26 22:20                 ` Andrew Waterman
2023-01-26  9:41             ` Jan Beulich
2023-01-26 23:27               ` Maciej W. Rozycki
2023-01-13 10:19 ` [PATCH 2/3] RISC-V: move OR and XOR aliases down Jan Beulich
2023-01-20  9:23   ` Ping: " Jan Beulich
2023-02-14  7:26   ` Jan Beulich
2023-01-13 10:20 ` [PATCH 3/3] RISC-V: prefer FSRM/FSFLAGS aliases for FSRMI/FSFLAGSI Jan Beulich

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=alpine.DEB.2.21.2301150420040.50462@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.com \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=nelson@rivosinc.com \
    --cc=palmer@dabbelt.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).