public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Waterman <andrew@sifive.com>
Cc: Binutils <binutils@sourceware.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Jim Wilson <jim.wilson.gcc@gmail.com>,
	Nelson Chu <nelson@rivosinc.com>,
	"Maciej W. Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
Date: Thu, 26 Jan 2023 10:35:40 +0100	[thread overview]
Message-ID: <8745742c-bbf4-7d12-73c2-50d2d4d58f22@suse.com> (raw)
In-Reply-To: <CA++6G0D-on1=AavpNkMjyLfKvxV=KiYs9m39FOSbEmd+gr6q+Q@mail.gmail.com>

On 26.01.2023 02:29, Andrew Waterman wrote:
> On Wed, Jan 25, 2023 at 7:22 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>>
>> On Wed, 25 Jan 2023, Jan Beulich wrote:
>>
>>>>  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.
>>>
>>> Aren't you changing topics? Being able to use alternative encodings to
>>> achieve the same effect isn't what we were talking about.
>>
>>  No, it just gives you background as to why some encodings are given
>> canonical aliases (used for disassembly) and why some are not.
>>
>>>>  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).
>>>
>>> Well, such a design imo ought to include a clear statement on uses of
>>> aliases. Iirc at least the 32-bit Arm ARM is very precise about what
>>> aliases exist, and it effectively mandates for at least some of them
>>> that they should be use in disassembly.
>>>
>>> As said before, I'd be happy to see things move in about any direction,
>>> just as long as the result is consistent and hence observable behavior
>>> is predictable for users of the assembler and disassembler.
>>
>>  It's been consistent so far AFAICT for the RISC-V assembly dialect (and
>> for that matter for the MIPS one as well).  If you disagree, then you're
>> welcome to present your view, but I think the context of libopcodes and
>> the binutils mailing list is not the correct place to discuss the assembly
>> language syntax.  You'd need to take it to the RISC-V ISA maintainters and
>> then we can implement whatever they've agreed to.
> 
> Precisely specifying the assembly syntax has been a weak spot of the
> RISC-V specs, but the general philosophy has been to encourage the use
> of aliases in situations that are seemingly obvious (e.g. ret vs. jalr
> x0, x1, 0) and to be consistent within a family of instructions (e.g.
> since add is an alias for addi, xor had better be an alias for xori).

Right, and then along exactly these lines slt{,u} better were aliases of
slti{,u}, with matching preference in disassembly. Hence the patch.

> On the disassembly side, the philosophy has been that more
> human-readable aliases should be used when appropriate (e.g. ret, not
> jalr x0, x1, 0), unless -Mno-aliases is specified (in which case e.g.
> jalr x0, x1, 0 should be printed).
> 
> The right place to document this stuff is here:
> https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md
> (I don't own this spec, so I'd recommend reporting problems or feature
> requests on the github issue tracker, rather than replying here).

Hmm, I'm pretty uncomfortable with discussion of things like that in
forms other than email. You may have noticed this already when I was
pointing out other observations and/or inconsistencies in some of the
spec.

Jan

  reply	other threads:[~2023-01-26  9: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
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 [this message]
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=8745742c-bbf4-7d12-73c2-50d2d4d58f22@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=macro@orcam.me.uk \
    --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).