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

[Jan Beulich <jbeulich@suse.com>]

On 15.01.2023 05:35, Maciej W. Rozycki wrote:
> On Fri, 13 Jan 2023, Jan Beulich via Binutils wrote:
> 
>> While not spelled out by the spec, gas has been supporting these aliases
>> virtually forever. Yet they were unused by the disassembler because of
>> sitting later in the table. Move the non-aliases down.
> 
>  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 ...

>  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.

>  Likewise with the remaining patches in this series.

Perhaps patch 3, but patch 2 doesn't alter disassembly (and has a
different purpose).

Jan