public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [RFC PATCH 0/1] RISC-V: Implement "extension variants" for diagnostics
@ 2022-10-01  5:27 Tsukasa OI
  2022-10-01  5:27 ` [RFC PATCH 1/1] RISC-V: Implement extension variants Tsukasa OI
  2022-10-01  7:21 ` [RFC PATCH 0/1] RISC-V: Implement "extension variants" for diagnostics Nelson Chu
  0 siblings, 2 replies; 6+ messages in thread
From: Tsukasa OI @ 2022-10-01  5:27 UTC (permalink / raw)
  To: Tsukasa OI, Nelson Chu, Kito Cheng, Palmer Dabbelt; +Cc: binutils

Hi all RISC-V folks,

GitHub tracker:
<https://github.com/a4lg/binutils-gdb/wiki/riscv_insn_ext_variants>

While investigating possible implementation of both 'Z[fdq]inx' and 'P'
implementations, I found something common (not just register pairs).

Here, this patch implements what I call "extension variants".
It was formerly a part of 'Zfinx' fixes (formerly the flag was named
"INSN_F_OR_X").

If there is a instruction with multiple variants with different requirements
and the assembler fails to parse all variants, there is a case that needs to
refer ALL variants to generate proper diagnostics.

If an instruction with "INSN_HAS_EXT_VARS" fails on all variants, the
assembler now has a chance to modify the instruction class for proper
diagnostics.  A typical use of this feature is to select wider instruction
class when necessary.


[Usage: CLZ instruction ('Zbpbo')]

To implement proposed 'Zbpbo' extension, updating instruction class for
CLZ instruction is not enough.  If we change CLZ instruction class from
"INSN_CLASS_ZBB" to "INSN_CLASS_ZBB_OR_ZBPBO", we will **mistakenly**
support that instruction on RV64_Zbpbo because CLZ on 'Zbpbo' is RV32-only.

Possible use with "INSN_HAS_EXT_VARS" is to define two variants of CLZ
instruction with that flag:

1.  'Zbb' (RV32/RV64)
2.  'Zbpbo' (RV32)

If both fails, we can widen the instruction class from "INSN_CLASS_ZBPBO"
to "INSN_CLASS_ZBB_OR_ZBPBO" if XLEN is 32.
After doing that, we will get following diagnostics:

-   On RV32: 'Zbb' or 'Zbpbo' is required
-   On RV64: 'Zbb' is required


[Usage: 'D'/'Zdinx' or 'Q'/'Zqinx']

Due to use of register pairs, we need to split 'D'/'Q' and 'Zdinx'/'Zqinx'
variants.  For instance, if parsing "fmin.d" fails on both 'D' and 'Zdinx'
variants, we have to require 'D' or 'Zdinx', not just 'Zdinx', the last
"fmin.d" variant in riscv_opcodes.

1.  'D'
2.  'Zdinx'

If both fails, we can widen the instruction class from "INSN_CLASS_ZDINX" to
"INSN_CLASS_D_OR_ZDINX".
After doing that, we will get diagnostics saying 'D' or 'Zdinx' is required.



Thanks,
Tsukasa




Tsukasa OI (1):
  RISC-V: Implement extension variants

 gas/config/tc-riscv.c  | 27 +++++++++++++++++++++++++--
 include/opcode/riscv.h |  5 +++++
 2 files changed, 30 insertions(+), 2 deletions(-)


base-commit: b4477c7f666bdeb7f8e998633c7b0cb62310b9ef
-- 
2.34.1


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-10-06 12:08 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-01  5:27 [RFC PATCH 0/1] RISC-V: Implement "extension variants" for diagnostics Tsukasa OI
2022-10-01  5:27 ` [RFC PATCH 1/1] RISC-V: Implement extension variants Tsukasa OI
2022-10-01  7:21 ` [RFC PATCH 0/1] RISC-V: Implement "extension variants" for diagnostics Nelson Chu
2022-10-01  8:25   ` Tsukasa OI
2022-10-06 11:12     ` Nelson Chu
2022-10-06 12:08       ` Tsukasa OI

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