* [PATCH 0/3] RISC-V: further alias insn handling adjustments
@ 2023-01-13 10:18 Jan Beulich
2023-01-13 10:19 ` [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U} Jan Beulich
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Jan Beulich @ 2023-01-13 10:18 UTC (permalink / raw)
To: Binutils; +Cc: Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
While "RISC-V: add alias for SLLI.UW" is still pending (presumably
no-one wants to commit to the alias without the doc spelling it out,
albeit that's a little odd considering that gas already supports
aliases not mandated by the doc - see patches 1 and 3 here), a few
more steps towards consistency look desirable.
1: prefer SLT{,U} aliases for SLTI{,U}
2: move OR and XOR aliases down
3: prefer FSRM/FSFLAGS aliases for FSRMI/FSFLAGSI
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-13 10:18 [PATCH 0/3] RISC-V: further alias insn handling adjustments Jan Beulich
@ 2023-01-13 10:19 ` Jan Beulich
2023-01-15 4:35 ` Maciej W. Rozycki
2023-01-13 10:19 ` [PATCH 2/3] RISC-V: move OR and XOR aliases down Jan Beulich
2023-01-13 10:20 ` [PATCH 3/3] RISC-V: prefer FSRM/FSFLAGS aliases for FSRMI/FSFLAGSI Jan Beulich
2 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-01-13 10:19 UTC (permalink / raw)
To: Binutils; +Cc: Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
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.
--- a/gas/testsuite/gas/riscv/insn.d
+++ b/gas/testsuite/gas/riscv/insn.d
@@ -45,6 +45,9 @@ Disassembly of section .text:
[^:]+: R_RISCV_JAL[ ]+target
[^:]+:[ ]+fa5ff56f[ ]+jal[ ]+a0,0 \<target\>
[^:]+: R_RISCV_JAL[ ]+target
+[^:]+:[ ]+0015a513[ ]+slt[ ]+a0,a1,1
+[^:]+:[ ]+0015b513[ ]+seqz[ ]+a0,a1
+[^:]+:[ ]+0025b513[ ]+sltu[ ]+a0,a1,2
[^:]+:[ ]+852e[ ]+mv[ ]+a0,a1
[^:]+:[ ]+0511[ ]+add[ ]+a0,a0,4 # .*
[^:]+:[ ]+002c[ ]+add[ ]+a1,sp,8
@@ -52,9 +55,9 @@ Disassembly of section .text:
[^:]+:[ ]+41a8[ ]+lw[ ]+a0,64\(a1\)
[^:]+:[ ]+c1a8[ ]+sw[ ]+a0,64\(a1\)
[^:]+:[ ]+8d6d[ ]+and[ ]+a0,a0,a1
-[^:]+:[ ]+d9c9[ ]+beqz[ ]+a1,0 \<target\>
+[^:]+:[ ]+d1d9[ ]+beqz[ ]+a1,0 \<target\>
[^:]+: R_RISCV_RVC_BRANCH[ ]+target
-[^:]+:[ ]+bf41[ ]+j[ ]+0 \<target\>
+[^:]+:[ ]+b751[ ]+j[ ]+0 \<target\>
[^:]+: R_RISCV_RVC_JUMP[ ]+target
[^:]+:[ ]+68c58543[ ]+fmadd.s[ ]+fa0,fa1,fa2,fa3,rne
[^:]+:[ ]+68c58543[ ]+fmadd.s[ ]+fa0,fa1,fa2,fa3,rne
--- a/gas/testsuite/gas/riscv/insn.s
+++ b/gas/testsuite/gas/riscv/insn.s
@@ -30,6 +30,10 @@ target:
.insn uj JAL, a0, target
.insn j JAL, a0, target
+ .insn i OP_IMM, 2, a0, a1, 1
+ .insn i OP_IMM, 3, a0, a1, 1
+ .insn i OP_IMM, 3, a0, a1, 2
+
.insn cr C2, 0x8, a0, a1
.insn ci C1, 0x0, a0, 4
.insn ciw C0, 0x0, a1, 1
--- a/gas/testsuite/gas/riscv/insn-dwarf.d
+++ b/gas/testsuite/gas/riscv/insn-dwarf.d
@@ -38,49 +38,52 @@ insn.s +29 +0x54.*
insn.s +30 +0x58.*
insn.s +31 +0x5c.*
insn.s +33 +0x60.*
-insn.s +34 +0x62.*
-insn.s +35 +0x64.*
-insn.s +36 +0x66.*
-insn.s +37 +0x68.*
-insn.s +38 +0x6a.*
-insn.s +39 +0x6c.*
-insn.s +40 +0x6e.*
-insn.s +41 +0x70.*
-insn.s +43 +0x72.*
-insn.s +44 +0x76.*
-insn.s +45 +0x7a.*
-insn.s +46 +0x7e.*
-insn.s +47 +0x82.*
-insn.s +48 +0x86.*
-insn.s +49 +0x8a.*
-insn.s +50 +0x8e.*
-insn.s +51 +0x92.*
-insn.s +52 +0x96.*
-insn.s +53 +0x9a.*
-insn.s +54 +0x9e.*
-insn.s +55 +0xa2.*
+insn.s +34 +0x64.*
+insn.s +35 +0x68.*
+insn.s +37 +0x6c.*
+insn.s +38 +0x6e.*
+insn.s +39 +0x70.*
+insn.s +40 +0x72.*
+insn.s +41 +0x74.*
+insn.s +42 +0x76.*
+insn.s +43 +0x78.*
+insn.s +44 +0x7a.*
+insn.s +45 +0x7c.*
+insn.s +47 +0x7e.*
+insn.s +48 +0x82.*
+insn.s +49 +0x86.*
+insn.s +50 +0x8a.*
+insn.s +51 +0x8e.*
+insn.s +52 +0x92.*
+insn.s +53 +0x96.*
+insn.s +54 +0x9a.*
+insn.s +55 +0x9e.*
+insn.s +56 +0xa2.*
insn.s +57 +0xa6.*
-insn.s +59 +0xaa.*
-insn.s +60 +0xac.*
-insn.s +61 +0xb0.*
-insn.s +62 +0xb6.*
-insn.s +63 +0xbe.*
-insn.s +64 +0xc8.*
-insn.s +65 +0xd4.*
-insn.s +66 +0xea.*
-insn.s +67 +0xec.*
-insn.s +68 +0xf0.*
-insn.s +69 +0xf6.*
-insn.s +70 +0xfe.*
-insn.s +71 +0x108.*
-insn.s +72 +0x114.*
-insn.s +74 +0x12a.*
-insn.s +75 +0x134.*
-insn.s +76 +0x13e.*
-insn.s +77 +0x154.*
-insn.s +78 +0x16a.*
-insn.s +79 +0x180.*
-insn.s +80 +0x196.*
-insn.s +81 +0x1ac.*
-insn.s +- +0x1c2
+insn.s +58 +0xaa.*
+insn.s +59 +0xae.*
+insn.s +61 +0xb2.*
+insn.s +63 +0xb6.*
+insn.s +64 +0xb8.*
+insn.s +65 +0xbc.*
+insn.s +66 +0xc2.*
+insn.s +67 +0xca.*
+insn.s +68 +0xd4.*
+insn.s +69 +0xe0.*
+insn.s +70 +0xf6.*
+insn.s +71 +0xf8.*
+insn.s +72 +0xfc.*
+insn.s +73 +0x102.*
+insn.s +74 +0x10a.*
+insn.s +75 +0x114.*
+insn.s +76 +0x120.*
+insn.s +78 +0x136.*
+insn.s +79 +0x140.*
+insn.s +80 +0x14a.*
+insn.s +81 +0x160.*
+insn.s +82 +0x176.*
+insn.s +83 +0x18c.*
+insn.s +84 +0x1a2.*
+insn.s +85 +0x1b8.*
+insn.s +- +0x1ce
#pass
--- a/gas/testsuite/gas/riscv/insn-na.d
+++ b/gas/testsuite/gas/riscv/insn-na.d
@@ -36,6 +36,9 @@ Disassembly of section .text:
[^:]+:[ ]+00fff537[ ]+lui[ ]+a0,0xfff
[^:]+:[ ]+fa9ff56f[ ]+jal[ ]+a0,0 \<target\>
[^:]+:[ ]+fa5ff56f[ ]+jal[ ]+a0,0 \<target\>
+[^:]+:[ ]+0015a513[ ]+slti[ ]+a0,a1,1
+[^:]+:[ ]+0015b513[ ]+sltiu[ ]+a0,a1,1
+[^:]+:[ ]+0025b513[ ]+sltiu[ ]+a0,a1,2
[^:]+:[ ]+852e[ ]+c\.mv[ ]+a0,a1
[^:]+:[ ]+0511[ ]+c\.addi[ ]+a0,4 # .*
[^:]+:[ ]+002c[ ]+c\.addi4spn[ ]+a1,sp,8
@@ -43,8 +46,8 @@ Disassembly of section .text:
[^:]+:[ ]+41a8[ ]+c\.lw[ ]+a0,64\(a1\)
[^:]+:[ ]+c1a8[ ]+c\.sw[ ]+a0,64\(a1\)
[^:]+:[ ]+8d6d[ ]+c\.and[ ]+a0,a1
-[^:]+:[ ]+d9c9[ ]+c\.beqz[ ]+a1,0 \<target\>
-[^:]+:[ ]+bf41[ ]+c\.j[ ]+0 \<target\>
+[^:]+:[ ]+d1d9[ ]+c\.beqz[ ]+a1,0 \<target\>
+[^:]+:[ ]+b751[ ]+c\.j[ ]+0 \<target\>
[^:]+:[ ]+68c58543[ ]+fmadd\.s[ ]+fa0,fa1,fa2,fa3,rne
[^:]+:[ ]+68c58543[ ]+fmadd\.s[ ]+fa0,fa1,fa2,fa3,rne
[^:]+:[ ]+68c58543[ ]+fmadd\.s[ ]+fa0,fa1,fa2,fa3,rne
--- a/opcodes/riscv-opc.c
+++ b/opcodes/riscv-opc.c
@@ -448,12 +448,12 @@ const struct riscv_opcode riscv_opcodes[
{"snez", 0, INSN_CLASS_I, "d,t", MATCH_SLTU, MASK_SLTU|MASK_RS1, match_opcode, INSN_ALIAS },
{"sltz", 0, INSN_CLASS_I, "d,s", MATCH_SLT, MASK_SLT|MASK_RS2, match_opcode, INSN_ALIAS },
{"sgtz", 0, INSN_CLASS_I, "d,t", MATCH_SLT, MASK_SLT|MASK_RS1, match_opcode, INSN_ALIAS },
-{"slti", 0, INSN_CLASS_I, "d,s,j", MATCH_SLTI, MASK_SLTI, match_opcode, 0 },
{"slt", 0, INSN_CLASS_I, "d,s,t", MATCH_SLT, MASK_SLT, match_opcode, 0 },
{"slt", 0, INSN_CLASS_I, "d,s,j", MATCH_SLTI, MASK_SLTI, match_opcode, INSN_ALIAS },
-{"sltiu", 0, INSN_CLASS_I, "d,s,j", MATCH_SLTIU, MASK_SLTIU, match_opcode, 0 },
+{"slti", 0, INSN_CLASS_I, "d,s,j", MATCH_SLTI, MASK_SLTI, match_opcode, 0 },
{"sltu", 0, INSN_CLASS_I, "d,s,t", MATCH_SLTU, MASK_SLTU, match_opcode, 0 },
{"sltu", 0, INSN_CLASS_I, "d,s,j", MATCH_SLTIU, MASK_SLTIU, match_opcode, INSN_ALIAS },
+{"sltiu", 0, INSN_CLASS_I, "d,s,j", MATCH_SLTIU, MASK_SLTIU, match_opcode, 0 },
{"sgt", 0, INSN_CLASS_I, "d,t,s", MATCH_SLT, MASK_SLT, match_opcode, INSN_ALIAS },
{"sgtu", 0, INSN_CLASS_I, "d,t,s", MATCH_SLTU, MASK_SLTU, match_opcode, INSN_ALIAS },
{"sb", 0, INSN_CLASS_I, "t,q(s)", MATCH_SB, MASK_SB, match_opcode, INSN_DREF|INSN_1_BYTE },
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/3] RISC-V: move OR and XOR aliases down
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-13 10:19 ` 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
2 siblings, 2 replies; 16+ messages in thread
From: Jan Beulich @ 2023-01-13 10:19 UTC (permalink / raw)
To: Binutils; +Cc: Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
While benign right now, everywhere else register forms come ahead of
immediate (alias) ones. That way both also end up next to their non-
alias (i-suffixed) forms, making it easier to see that the pairs are
identical (except for INSN_ALIAS of course).
--- a/opcodes/riscv-opc.c
+++ b/opcodes/riscv-opc.c
@@ -438,10 +438,10 @@ const struct riscv_opcode riscv_opcodes[
{"lw", 0, INSN_CLASS_I, "d,o(s)", MATCH_LW, MASK_LW, match_opcode, INSN_DREF|INSN_4_BYTE },
{"lw", 0, INSN_CLASS_I, "d,A", 0, (int) M_LW, match_never, INSN_MACRO },
{"not", 0, INSN_CLASS_I, "d,s", MATCH_XORI|MASK_IMM, MASK_XORI|MASK_IMM, match_opcode, INSN_ALIAS },
-{"or", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, INSN_ALIAS },
{"or", 0, INSN_CLASS_C, "Cs,Cw,Ct", MATCH_C_OR, MASK_C_OR, match_opcode, INSN_ALIAS },
{"or", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_OR, MASK_C_OR, match_opcode, INSN_ALIAS },
{"or", 0, INSN_CLASS_I, "d,s,t", MATCH_OR, MASK_OR, match_opcode, 0 },
+{"or", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, INSN_ALIAS },
{"ori", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, 0 },
{"auipc", 0, INSN_CLASS_I, "d,u", MATCH_AUIPC, MASK_AUIPC, match_opcode, 0 },
{"seqz", 0, INSN_CLASS_I, "d,s", MATCH_SLTIU|ENCODE_ITYPE_IMM (1), MASK_SLTIU | MASK_IMM, match_opcode, INSN_ALIAS },
@@ -476,10 +476,10 @@ const struct riscv_opcode riscv_opcodes[
{"rdtimeh", 32, INSN_CLASS_I, "d", MATCH_RDTIMEH, MASK_RDTIMEH, match_opcode, INSN_ALIAS },
{"ecall", 0, INSN_CLASS_I, "", MATCH_SCALL, MASK_SCALL, match_opcode, 0 },
{"scall", 0, INSN_CLASS_I, "", MATCH_SCALL, MASK_SCALL, match_opcode, 0 },
-{"xor", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, INSN_ALIAS },
{"xor", 0, INSN_CLASS_C, "Cs,Cw,Ct", MATCH_C_XOR, MASK_C_XOR, match_opcode, INSN_ALIAS },
{"xor", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_XOR, MASK_C_XOR, match_opcode, INSN_ALIAS },
{"xor", 0, INSN_CLASS_I, "d,s,t", MATCH_XOR, MASK_XOR, match_opcode, 0 },
+{"xor", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, INSN_ALIAS },
{"xori", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, 0 },
{"lwu", 64, INSN_CLASS_I, "d,o(s)", MATCH_LWU, MASK_LWU, match_opcode, INSN_DREF|INSN_4_BYTE },
{"lwu", 64, INSN_CLASS_I, "d,A", 0, (int) M_LWU, match_never, INSN_MACRO },
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 3/3] RISC-V: prefer FSRM/FSFLAGS aliases for FSRMI/FSFLAGSI
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-13 10:19 ` [PATCH 2/3] RISC-V: move OR and XOR aliases down Jan Beulich
@ 2023-01-13 10:20 ` Jan Beulich
2 siblings, 0 replies; 16+ messages in thread
From: Jan Beulich @ 2023-01-13 10:20 UTC (permalink / raw)
To: Binutils; +Cc: Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
While not spelled out by the spec, gas has been supporting these
i-suffixed aliases almost forever. However, unlike other insns with
immediate operands, i-suffix-less aliases were missing. Add such,
paralleling in particular CSR*I having CSR* aliases.
--- a/gas/testsuite/gas/riscv/csr-insns-pseudo.d
+++ b/gas/testsuite/gas/riscv/csr-insns-pseudo.d
@@ -27,10 +27,10 @@ Disassembly of section .text:
[ ]+[0-9a-f]+:[ ]+002022f3[ ]+frrm[ ]+t0
[ ]+[0-9a-f]+:[ ]+002312f3[ ]+fsrm[ ]+t0,t1
[ ]+[0-9a-f]+:[ ]+00231073[ ]+fsrm[ ]+t1
-[ ]+[0-9a-f]+:[ ]+002fd2f3[ ]+fsrmi[ ]+t0,31
-[ ]+[0-9a-f]+:[ ]+002fd073[ ]+fsrmi[ ]+zero,31
+[ ]+[0-9a-f]+:[ ]+002fd2f3[ ]+fsrm[ ]+t0,31
+[ ]+[0-9a-f]+:[ ]+002fd073[ ]+fsrm[ ]+zero,31
[ ]+[0-9a-f]+:[ ]+001022f3[ ]+frflags[ ]+t0
[ ]+[0-9a-f]+:[ ]+001312f3[ ]+fsflags[ ]+t0,t1
[ ]+[0-9a-f]+:[ ]+00131073[ ]+fsflags[ ]+t1
-[ ]+[0-9a-f]+:[ ]+001fd2f3[ ]+fsflagsi[ ]+t0,31
-[ ]+[0-9a-f]+:[ ]+001fd073[ ]+fsflagsi[ ]+zero,31
+[ ]+[0-9a-f]+:[ ]+001fd2f3[ ]+fsflags[ ]+t0,31
+[ ]+[0-9a-f]+:[ ]+001fd073[ ]+fsflags[ ]+zero,31
--- a/gas/testsuite/gas/riscv/csr-insns-pseudo-zfinx.d
+++ b/gas/testsuite/gas/riscv/csr-insns-pseudo-zfinx.d
@@ -27,10 +27,10 @@ Disassembly of section .text:
[ ]+[0-9a-f]+:[ ]+002022f3[ ]+frrm[ ]+t0
[ ]+[0-9a-f]+:[ ]+002312f3[ ]+fsrm[ ]+t0,t1
[ ]+[0-9a-f]+:[ ]+00231073[ ]+fsrm[ ]+t1
-[ ]+[0-9a-f]+:[ ]+002fd2f3[ ]+fsrmi[ ]+t0,31
-[ ]+[0-9a-f]+:[ ]+002fd073[ ]+fsrmi[ ]+zero,31
+[ ]+[0-9a-f]+:[ ]+002fd2f3[ ]+fsrm[ ]+t0,31
+[ ]+[0-9a-f]+:[ ]+002fd073[ ]+fsrm[ ]+zero,31
[ ]+[0-9a-f]+:[ ]+001022f3[ ]+frflags[ ]+t0
[ ]+[0-9a-f]+:[ ]+001312f3[ ]+fsflags[ ]+t0,t1
[ ]+[0-9a-f]+:[ ]+00131073[ ]+fsflags[ ]+t1
-[ ]+[0-9a-f]+:[ ]+001fd2f3[ ]+fsflagsi[ ]+t0,31
-[ ]+[0-9a-f]+:[ ]+001fd073[ ]+fsflagsi[ ]+zero,31
+[ ]+[0-9a-f]+:[ ]+001fd2f3[ ]+fsflags[ ]+t0,31
+[ ]+[0-9a-f]+:[ ]+001fd073[ ]+fsflags[ ]+zero,31
--- a/gas/testsuite/gas/riscv/fsxxi.d
+++ b/gas/testsuite/gas/riscv/fsxxi.d
@@ -7,7 +7,7 @@
Disassembly of section .text:
0+000 <.text>:
-[ ]+0:[ ]+002fd573[ ]+fsrmi[ ]+a0,31
-[ ]+4:[ ]+002f5073[ ]+fsrmi[ ]+zero,30
-[ ]+8:[ ]+001ed773[ ]+fsflagsi[ ]+a4,29
-[ ]+c:[ ]+001e5073[ ]+fsflagsi[ ]+zero,28
+[ ]+0:[ ]+002fd573[ ]+fsrm[ ]+a0,31
+[ ]+4:[ ]+002f5073[ ]+fsrm[ ]+zero,30
+[ ]+8:[ ]+001ed773[ ]+fsflags[ ]+a4,29
+[ ]+c:[ ]+001e5073[ ]+fsflags[ ]+zero,28
--- a/opcodes/riscv-opc.c
+++ b/opcodes/riscv-opc.c
@@ -693,11 +693,15 @@ const struct riscv_opcode riscv_opcodes[
{"frrm", 0, INSN_CLASS_F_INX, "d", MATCH_FRRM, MASK_FRRM, match_opcode, INSN_ALIAS },
{"fsrm", 0, INSN_CLASS_F_INX, "s", MATCH_FSRM, MASK_FSRM|MASK_RD, match_opcode, INSN_ALIAS },
{"fsrm", 0, INSN_CLASS_F_INX, "d,s", MATCH_FSRM, MASK_FSRM, match_opcode, INSN_ALIAS },
+{"fsrm", 0, INSN_CLASS_F_INX, "d,Z", MATCH_FSRMI, MASK_FSRMI, match_opcode, INSN_ALIAS },
+{"fsrm", 0, INSN_CLASS_F_INX, "Z", MATCH_FSRMI, MASK_FSRMI|MASK_RD, match_opcode, INSN_ALIAS },
{"fsrmi", 0, INSN_CLASS_F_INX, "d,Z", MATCH_FSRMI, MASK_FSRMI, match_opcode, INSN_ALIAS },
{"fsrmi", 0, INSN_CLASS_F_INX, "Z", MATCH_FSRMI, MASK_FSRMI|MASK_RD, match_opcode, INSN_ALIAS },
{"frflags", 0, INSN_CLASS_F_INX, "d", MATCH_FRFLAGS, MASK_FRFLAGS, match_opcode, INSN_ALIAS },
{"fsflags", 0, INSN_CLASS_F_INX, "s", MATCH_FSFLAGS, MASK_FSFLAGS|MASK_RD, match_opcode, INSN_ALIAS },
{"fsflags", 0, INSN_CLASS_F_INX, "d,s", MATCH_FSFLAGS, MASK_FSFLAGS, match_opcode, INSN_ALIAS },
+{"fsflags", 0, INSN_CLASS_F_INX, "d,Z", MATCH_FSFLAGSI, MASK_FSFLAGSI, match_opcode, INSN_ALIAS },
+{"fsflags", 0, INSN_CLASS_F_INX, "Z", MATCH_FSFLAGSI, MASK_FSFLAGSI|MASK_RD, match_opcode, INSN_ALIAS },
{"fsflagsi", 0, INSN_CLASS_F_INX, "d,Z", MATCH_FSFLAGSI, MASK_FSFLAGSI, match_opcode, INSN_ALIAS },
{"fsflagsi", 0, INSN_CLASS_F_INX, "Z", MATCH_FSFLAGSI, MASK_FSFLAGSI|MASK_RD, match_opcode, INSN_ALIAS },
{"flw", 32, INSN_CLASS_F_AND_C, "D,Cm(Cc)", MATCH_C_FLWSP, MASK_C_FLWSP, match_opcode, INSN_ALIAS|INSN_DREF|INSN_4_BYTE },
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
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
0 siblings, 1 reply; 16+ messages in thread
From: Maciej W. Rozycki @ 2023-01-15 4:35 UTC (permalink / raw)
To: Jan Beulich
Cc: Binutils, Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
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.
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.
Likewise with the remaining patches in this series.
Maciej
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-15 4:35 ` Maciej W. Rozycki
@ 2023-01-16 7:46 ` Jan Beulich
2023-01-25 0:42 ` Maciej W. Rozycki
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-01-16 7:46 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Binutils, Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Ping: [PATCH 2/3] RISC-V: move OR and XOR aliases down
2023-01-13 10:19 ` [PATCH 2/3] RISC-V: move OR and XOR aliases down Jan Beulich
@ 2023-01-20 9:23 ` Jan Beulich
2023-02-14 7:26 ` Jan Beulich
1 sibling, 0 replies; 16+ messages in thread
From: Jan Beulich @ 2023-01-20 9:23 UTC (permalink / raw)
To: Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu; +Cc: Binutils
On 13.01.2023 11:19, Jan Beulich via Binutils wrote:
> While benign right now, everywhere else register forms come ahead of
> immediate (alias) ones. That way both also end up next to their non-
> alias (i-suffixed) forms, making it easier to see that the pairs are
> identical (except for INSN_ALIAS of course).
Considering other replies I understand that patches 1 and 3 may be
controversial, and a different route wants actually taking towards
consistency. But I think the change here is orthogonal to that (yet
to be had) discussion, so may I ask for arch maintainer approval
here?
Thanks, Jan
> --- a/opcodes/riscv-opc.c
> +++ b/opcodes/riscv-opc.c
> @@ -438,10 +438,10 @@ const struct riscv_opcode riscv_opcodes[
> {"lw", 0, INSN_CLASS_I, "d,o(s)", MATCH_LW, MASK_LW, match_opcode, INSN_DREF|INSN_4_BYTE },
> {"lw", 0, INSN_CLASS_I, "d,A", 0, (int) M_LW, match_never, INSN_MACRO },
> {"not", 0, INSN_CLASS_I, "d,s", MATCH_XORI|MASK_IMM, MASK_XORI|MASK_IMM, match_opcode, INSN_ALIAS },
> -{"or", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, INSN_ALIAS },
> {"or", 0, INSN_CLASS_C, "Cs,Cw,Ct", MATCH_C_OR, MASK_C_OR, match_opcode, INSN_ALIAS },
> {"or", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_OR, MASK_C_OR, match_opcode, INSN_ALIAS },
> {"or", 0, INSN_CLASS_I, "d,s,t", MATCH_OR, MASK_OR, match_opcode, 0 },
> +{"or", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, INSN_ALIAS },
> {"ori", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, 0 },
> {"auipc", 0, INSN_CLASS_I, "d,u", MATCH_AUIPC, MASK_AUIPC, match_opcode, 0 },
> {"seqz", 0, INSN_CLASS_I, "d,s", MATCH_SLTIU|ENCODE_ITYPE_IMM (1), MASK_SLTIU | MASK_IMM, match_opcode, INSN_ALIAS },
> @@ -476,10 +476,10 @@ const struct riscv_opcode riscv_opcodes[
> {"rdtimeh", 32, INSN_CLASS_I, "d", MATCH_RDTIMEH, MASK_RDTIMEH, match_opcode, INSN_ALIAS },
> {"ecall", 0, INSN_CLASS_I, "", MATCH_SCALL, MASK_SCALL, match_opcode, 0 },
> {"scall", 0, INSN_CLASS_I, "", MATCH_SCALL, MASK_SCALL, match_opcode, 0 },
> -{"xor", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, INSN_ALIAS },
> {"xor", 0, INSN_CLASS_C, "Cs,Cw,Ct", MATCH_C_XOR, MASK_C_XOR, match_opcode, INSN_ALIAS },
> {"xor", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_XOR, MASK_C_XOR, match_opcode, INSN_ALIAS },
> {"xor", 0, INSN_CLASS_I, "d,s,t", MATCH_XOR, MASK_XOR, match_opcode, 0 },
> +{"xor", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, INSN_ALIAS },
> {"xori", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, 0 },
> {"lwu", 64, INSN_CLASS_I, "d,o(s)", MATCH_LWU, MASK_LWU, match_opcode, INSN_DREF|INSN_4_BYTE },
> {"lwu", 64, INSN_CLASS_I, "d,A", 0, (int) M_LWU, match_never, INSN_MACRO },
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-16 7:46 ` Jan Beulich
@ 2023-01-25 0:42 ` Maciej W. Rozycki
2023-01-25 15:02 ` Jan Beulich
0 siblings, 1 reply; 16+ messages in thread
From: Maciej W. Rozycki @ 2023-01-25 0:42 UTC (permalink / raw)
To: Jan Beulich
Cc: Binutils, Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
On Mon, 16 Jan 2023, Jan Beulich wrote:
> > 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 ...
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.
> > 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.
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).
NB the POWER ISA also uses different mnemonics in its assembly dialect for
immediate ALU ("i") or indexed memory ("x") machine operations vs their
register or displacement variants. There are other such assembly dialects
I suppose (IIRC Intel 8080 is like that and unlike Zilog Z80, despite the
backwards compatibility of the ISA).
> > Likewise with the remaining patches in this series.
>
> Perhaps patch 3, but patch 2 doesn't alter disassembly (and has a
> different purpose).
Ack. FWIW I think grouping aliases together has a value, but I have no
strong opinion here. The implementation mandates that encodings reusing
the same mnemonic be grouped together and that limits the ordering options
available, i.e. you can't have all aliases at the beginning of the table
and you can't have all the entries encoding the same machine operation
next to each other either.
Maciej
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-25 0:42 ` Maciej W. Rozycki
@ 2023-01-25 15:02 ` Jan Beulich
2023-01-25 15:22 ` Maciej W. Rozycki
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-01-25 15:02 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Binutils, Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
On 25.01.2023 01:42, Maciej W. Rozycki wrote:
> On Mon, 16 Jan 2023, Jan Beulich wrote:
>
>>> 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 ...
>
> 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.
>>> 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.
>
> 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.
> NB the POWER ISA also uses different mnemonics in its assembly dialect for
> immediate ALU ("i") or indexed memory ("x") machine operations vs their
> register or displacement variants.
Of course, as they're permitting plain numbers to represent register
operands.
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
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:41 ` Jan Beulich
0 siblings, 2 replies; 16+ messages in thread
From: Maciej W. Rozycki @ 2023-01-25 15:22 UTC (permalink / raw)
To: Jan Beulich
Cc: Binutils, Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
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.
Maciej
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-25 15:22 ` Maciej W. Rozycki
@ 2023-01-26 1:29 ` Andrew Waterman
2023-01-26 9:35 ` Jan Beulich
2023-01-26 9:41 ` Jan Beulich
1 sibling, 1 reply; 16+ messages in thread
From: Andrew Waterman @ 2023-01-26 1:29 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Jan Beulich, Binutils, Palmer Dabbelt, Jim Wilson, Nelson Chu
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).
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).
>
> Maciej
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-26 1:29 ` Andrew Waterman
@ 2023-01-26 9:35 ` Jan Beulich
2023-01-26 22:20 ` Andrew Waterman
0 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-01-26 9:35 UTC (permalink / raw)
To: Andrew Waterman
Cc: Binutils, Palmer Dabbelt, Jim Wilson, Nelson Chu, Maciej W. Rozycki
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-25 15:22 ` Maciej W. Rozycki
2023-01-26 1:29 ` Andrew Waterman
@ 2023-01-26 9:41 ` Jan Beulich
2023-01-26 23:27 ` Maciej W. Rozycki
1 sibling, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2023-01-26 9:41 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Binutils, Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
On 25.01.2023 16:22, Maciej W. Rozycki 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.
This, I'm afraid, is again a biased view. ISA and assembly syntax aren't
necessarily connected. See the (odd in my personal view) AT&T syntax which
has been the favorite one in the Unix world for x86, yet is entirely
disconnected from the ISA specifications coming from the relevant x86
vendors (all using so called Intel syntax, which really dates back to
MASM / TASM). Of course an architecture is free to define a "preferred"
assembly language, but I guess that's still distinct from the ISA spec,
and I'm unaware of a specific assembly syntax spec for RISC-V (which
Andrew's reply looks to support).
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-26 9:35 ` Jan Beulich
@ 2023-01-26 22:20 ` Andrew Waterman
0 siblings, 0 replies; 16+ messages in thread
From: Andrew Waterman @ 2023-01-26 22:20 UTC (permalink / raw)
To: Jan Beulich
Cc: Binutils, Palmer Dabbelt, Jim Wilson, Nelson Chu, Maciej W. Rozycki
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U}
2023-01-26 9:41 ` Jan Beulich
@ 2023-01-26 23:27 ` Maciej W. Rozycki
0 siblings, 0 replies; 16+ messages in thread
From: Maciej W. Rozycki @ 2023-01-26 23:27 UTC (permalink / raw)
To: Jan Beulich
Cc: Binutils, Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
On Thu, 26 Jan 2023, Jan Beulich wrote:
> This, I'm afraid, is again a biased view. ISA and assembly syntax aren't
> necessarily connected. See the (odd in my personal view) AT&T syntax which
> has been the favorite one in the Unix world for x86, yet is entirely
> disconnected from the ISA specifications coming from the relevant x86
> vendors (all using so called Intel syntax, which really dates back to
> MASM / TASM).
I don't think this example is really good here. AFAIK the AT&T syntax
predates what Microsoft invented with MASM and said company is quite known
for not respecting established standards, whether formal or de facto.
NB I find the MASM dialect odd and excessively elaborate with its "WORD
PTR", etc. constructs even though I knew it first (back in ~1991). Most
assembly language dialects I came across are actually closer to x86 AT&T
than to MASM.
> [...] Of course an architecture is free to define a "preferred"
> assembly language, but I guess that's still distinct from the ISA spec,
> and I'm unaware of a specific assembly syntax spec for RISC-V (which
> Andrew's reply looks to support).
However I think syntax shouldn't be changed in an ad-hoc manner, because
we want consistency and existing software to continue working. We've had
RISC-V support 6 years now in upstream binutils, so one can't really say
it's still in its infancy anymore.
FWIW,
Maciej
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] RISC-V: move OR and XOR aliases down
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
1 sibling, 0 replies; 16+ messages in thread
From: Jan Beulich @ 2023-02-14 7:26 UTC (permalink / raw)
To: Binutils; +Cc: Palmer Dabbelt, Andrew Waterman, Jim Wilson, Nelson Chu
On 13.01.2023 11:19, Jan Beulich via Binutils wrote:
> While benign right now, everywhere else register forms come ahead of
> immediate (alias) ones. That way both also end up next to their non-
> alias (i-suffixed) forms, making it easier to see that the pairs are
> identical (except for INSN_ALIAS of course).
With the equate considerations in [1] it may actually be the case that
the adjustments want to be the other way around, for all immediate
operand aliases to come ahead of their otherwise similar register-only
forms. Yet as said there - first of all it needs to be established
what the intended (and then consistent) behavior is to be.
Jan
[1] https://sourceware.org/pipermail/binutils/2023-February/125993.html
> --- a/opcodes/riscv-opc.c
> +++ b/opcodes/riscv-opc.c
> @@ -438,10 +438,10 @@ const struct riscv_opcode riscv_opcodes[
> {"lw", 0, INSN_CLASS_I, "d,o(s)", MATCH_LW, MASK_LW, match_opcode, INSN_DREF|INSN_4_BYTE },
> {"lw", 0, INSN_CLASS_I, "d,A", 0, (int) M_LW, match_never, INSN_MACRO },
> {"not", 0, INSN_CLASS_I, "d,s", MATCH_XORI|MASK_IMM, MASK_XORI|MASK_IMM, match_opcode, INSN_ALIAS },
> -{"or", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, INSN_ALIAS },
> {"or", 0, INSN_CLASS_C, "Cs,Cw,Ct", MATCH_C_OR, MASK_C_OR, match_opcode, INSN_ALIAS },
> {"or", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_OR, MASK_C_OR, match_opcode, INSN_ALIAS },
> {"or", 0, INSN_CLASS_I, "d,s,t", MATCH_OR, MASK_OR, match_opcode, 0 },
> +{"or", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, INSN_ALIAS },
> {"ori", 0, INSN_CLASS_I, "d,s,j", MATCH_ORI, MASK_ORI, match_opcode, 0 },
> {"auipc", 0, INSN_CLASS_I, "d,u", MATCH_AUIPC, MASK_AUIPC, match_opcode, 0 },
> {"seqz", 0, INSN_CLASS_I, "d,s", MATCH_SLTIU|ENCODE_ITYPE_IMM (1), MASK_SLTIU | MASK_IMM, match_opcode, INSN_ALIAS },
> @@ -476,10 +476,10 @@ const struct riscv_opcode riscv_opcodes[
> {"rdtimeh", 32, INSN_CLASS_I, "d", MATCH_RDTIMEH, MASK_RDTIMEH, match_opcode, INSN_ALIAS },
> {"ecall", 0, INSN_CLASS_I, "", MATCH_SCALL, MASK_SCALL, match_opcode, 0 },
> {"scall", 0, INSN_CLASS_I, "", MATCH_SCALL, MASK_SCALL, match_opcode, 0 },
> -{"xor", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, INSN_ALIAS },
> {"xor", 0, INSN_CLASS_C, "Cs,Cw,Ct", MATCH_C_XOR, MASK_C_XOR, match_opcode, INSN_ALIAS },
> {"xor", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_XOR, MASK_C_XOR, match_opcode, INSN_ALIAS },
> {"xor", 0, INSN_CLASS_I, "d,s,t", MATCH_XOR, MASK_XOR, match_opcode, 0 },
> +{"xor", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, INSN_ALIAS },
> {"xori", 0, INSN_CLASS_I, "d,s,j", MATCH_XORI, MASK_XORI, match_opcode, 0 },
> {"lwu", 64, INSN_CLASS_I, "d,o(s)", MATCH_LWU, MASK_LWU, match_opcode, INSN_DREF|INSN_4_BYTE },
> {"lwu", 64, INSN_CLASS_I, "d,A", 0, (int) M_LWU, match_never, INSN_MACRO },
>
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-02-14 7:26 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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).