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
next prev parent 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).