Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}

[Andrew Waterman <andrew@sifive.com>]

On Thu, Jan 26, 2023 at 1:35 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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.

Ah, that's fine, of course.  I (and others) don't mind filing tickets
as a consequence of these email discussions, as long as we know we
need to do so.

>
> Jan