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: Wed, 25 Jan 2023 00:42:10 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2301161235380.50462@angie.orcam.me.uk> (raw)
In-Reply-To: <f438b9f9-33fd-c569-8f35-5d03ac936265@suse.com>

On Mon, 16 Jan 2023, Jan Beulich wrote:

> >  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.
> 
> I can see this as a way to look at things, but then there need to be
> changes in the other direction (after all patches 1 and 3 here merely
> follow existing practice). Plus, perhaps more importantly, if you
> don't strictly prefer aliases over "real" insns, then first of all it
> needs establishing (and writing down) where to draw the boundary.
> 
> My view is that the "i" in the name is needlessly distinguishing the
> mnemonics from their non-immediate counterparts (i.e. I view
> "improvement" vs "obfuscation the other way around"). I'm surely
> biased from architectures like x86, IA-64, or Arm, where mnemonic
> names don't try to duplicate what's expressed by operands. Much like
> you ...

 This is however what these instructions have been named in the ISA and 
the assembly dialect.  In the case of NOP, MOVE, etc. mnemonics they are 
significant assembly idioms (usually mentioned in the ISA manual) and 
there are sometimes thousands of alternative encodings that could be used 
to effect the same operation, but only the chosen canonical encoding is 
disassembled this way.

> >  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.
> 
> ... may be biased by your MIPS experience.

 It's rather how the assembly language has been designed (FWIW the RISC-V 
ISA and assembly dialect have been largely inspired by the MIPS approach).  
NB the POWER ISA also uses different mnemonics in its assembly dialect for 
immediate ALU ("i") or indexed memory ("x") machine operations vs their 
register or displacement variants.  There are other such assembly dialects 
I suppose (IIRC Intel 8080 is like that and unlike Zilog Z80, despite the 
backwards compatibility of the ISA).

> >  Likewise with the remaining patches in this series.
> 
> Perhaps patch 3, but patch 2 doesn't alter disassembly (and has a
> different purpose).

 Ack.  FWIW I think grouping aliases together has a value, but I have no 
strong opinion here.  The implementation mandates that encodings reusing 
the same mnemonic be grouped together and that limits the ordering options 
available, i.e. you can't have all aliases at the beginning of the table 
and you can't have all the entries encoding the same machine operation 
next to each other either.

  Maciej

  reply	other threads:[~2023-01-25  0:42 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
2023-01-16  7:46     ` Jan Beulich
2023-01-25  0:42       ` Maciej W. Rozycki [this message]
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.2301161235380.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).