public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: jbeulich@suse.com, nelson@rivosinc.com
Cc: Andrew Waterman <andrew@sifive.com>,
	Jim Wilson <jim.wilson.gcc@gmail.com>,
	binutils@sourceware.org, research_trasio@irq.a4lg.com
Subject: Re: [PATCH] RISC-V: move various alias entries
Date: Fri, 25 Aug 2023 06:23:21 -0700 (PDT)	[thread overview]
Message-ID: <mhng-e168f3d3-2749-4aa5-9a7a-afd6f18d6273@palmer-ri-x1c9> (raw)
In-Reply-To: <2d277339-6428-4197-6951-4698ede1edef@suse.com>

On Fri, 25 Aug 2023 06:01:07 PDT (-0700), jbeulich@suse.com wrote:
> On 05.08.2023 03:40, Tsukasa OI wrote:
>> On 2023/08/04 21:00, Jan Beulich via Binutils wrote:
>>> For disassembly to only use spec-mandated aliases, respective non-alias
>>> entries need to come ahead of their alias ones. Since identical
>>> mnemonics need to stay together, whole groups are moved up where
>>> necessary.
>>>
>>> This partly reverts 839189bc932e ("RISC-V: re-arrange opcode table for
>>> consistent alias handling"), but then also goes beyond a plain revert.
>>> ---
>>> I did not adjust JAL back, to continue to match JALR. The spec doesn't
>>> spell out how operands are to be specified, and hence it also doesn't
>>> mention how many explicit ones there are supposed to be.
>>>
>>> What about NEG, NEGW, and RET (and perhaps more)? The spec doesn't know
>>> of those afaics.
>>
>> I think JAL, NEG, NEGW and RET are okay as is.
>>
>> For JAL, I support Jan's opinion.
>>
>> For all instructions Jan pointed out (including JAL with one operand),
>> they are listed in the RISC-V Assembly Programmer's Manual:
>> <https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md>
>> and should be considered safe
>> (unlike "add rd, rs1, IMM" == "addi rd, rs1, IMM").

IMO that's a reasonable rationale.  The various RISC-V specs define 
things in surprising places all the time, but users already need to deal 
with that and there's really nothing we can do to change it.  At least 
this way we're generating disassembly that is defined somewhere, so 
there's a better chance they'll be able to figue out what the mnemonics 
mean.

>> I support merging this patch without modification (or perhaps, with
>> minor modification to the commit message?).
>>
>> Reviewed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
>
> Arch maintainers - any view? I guess I'll wait another week or so and
> commit if I don't hear anything to the contrary.

Sorry for missing this.  It looks good to me, so

Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>

but I remember talking about it at some point with Nelson.  It's the 
weekend already in Taiwain, so I'll try to remember to bug him on Monday 
if he doesn't see this.

>
> Jan

  reply	other threads:[~2023-08-25 13:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04 12:00 Jan Beulich
2023-08-05  1:40 ` Tsukasa OI
2023-08-25 13:01   ` Jan Beulich
2023-08-25 13:23     ` Palmer Dabbelt [this message]
2023-08-28  2:21       ` Nelson Chu

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=mhng-e168f3d3-2749-4aa5-9a7a-afd6f18d6273@palmer-ri-x1c9 \
    --to=palmer@dabbelt.com \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.com \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=nelson@rivosinc.com \
    --cc=research_trasio@irq.a4lg.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).