[PATCH 0/1] RISC-V: Add 'H' to canonical extension ordering

[PATCH 0/1] RISC-V: Add 'H' to canonical extension ordering

[Tsukasa OI]

Hello,

I was making bigger patchset that supports all Zfh/Zfhmin/Zhinx/Zhinxmin
and this work is a part of it.  I felt this particular patch is urgent.


To implement Zhinx/Zhinxmin extensions, we have to determine where to
place Zh* extensions.  To resolve this problem, I raised an issue on
RISC-V ISA Manual GitHub:
<https://github.com/riscv/riscv-isa-manual/issues/837>

...and we made a consensus.  We will put 'H' after 'V'.  Considering
compatibility with QEMU and LLVM, we can put 'H' after 'N' (making
'P' -> 'V' -> 'N' -> 'H' canonical ordering for compatibility).

Although this kind of canonical ordering is not ratified yet, it's at
least worth prototyping now.



This makes two crucial differences:
1.  In -march option allowed
2.  In .riscv.attributes section


1. -march option allowed

On a machine with GPR-FP support for 16, 32 and 64-bit floating point
numbers, Jiawei's patch allows:
    -march=rv64imac_zhinx_zicsr_zifencei_zdinx
but my upcoming patch allows:
    -march=rv64imac_zicsr_zifencei_zdinx_zhinx

Note that Jiawei's patch (now merged) requires Zhinx to be placed before
Zi* extensions.

The latter will be canonical.  But considering canonical ordering is
too much for regular developers, former should be made valid on future
patches.


2. .riscv.attributes section

With Jiawei's patch:
    Contents of section .riscv.attributes:
    Contents of section .riscv.attributes:
    0000 41580000 00726973 63760001 4e000000  AX...riscv..N...
    0010 05727636 34693270 315f6d32 70305f61  .rv64i2p1_m2p0_a
    0020 3270315f 63327030 5f7a6869 6e783170  2p1_c2p0_zhinx1p
    0030 305f7a69 63737232 70305f7a 6966656e  0_zicsr2p0_zifen
    0040 63656932 70305f7a 66696e78 3170305f  cei2p0_zfinx1p0_
    0050 7a64696e 78317030 00                 zdinx1p0.       

With Jiawei's and this patch:
    Contents of section .riscv.attributes:
    0000 41580000 00726973 63760001 4e000000  AX...riscv..N...
    0010 05727636 34693270 315f6d32 70305f61  .rv64i2p1_m2p0_a
    0020 3270315f 63327030 5f7a6963 73723270  2p1_c2p0_zicsr2p
    0030 305f7a69 66656e63 65693270 305f7a66  0_zifencei2p0_zf
    0040 696e7831 70305f7a 64696e78 3170305f  inx1p0_zdinx1p0_
    0050 7a68696e 78317030 00                 zhinx1p0.       

Just like in -march, there is a difference on Zhinx extension location.

Again, this kind of difference should be handled by future toolchains.
But it's worth making extension ordering canonical as possible, for now.





If 'H' extension is going to be version 1.0, it's not a bad time to
implement 'H' extension itself (since one of the two biggest obstacle
to implement actual 'H' extension will go with this patch).

Thanks,
Tsukasa




Tsukasa OI (1):
  RISC-V: Add 'H' to canonical extension ordering

 bfd/elfxx-riscv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: b0de9ed86f3af84fbd636f94a58b9c4ad7f4e743
-- 
2.34.1

[PATCH 1/1] RISC-V: Add 'H' to canonical extension ordering

[Tsukasa OI]

This commit adds 'H' to canonical extension ordering based on current
consensus (not officially ratified as a new ISA specification manual
but discussion for software compatibility is made).

bfd/ChangeLog

	* elfxx-riscv.c (riscv_ext_canonical_order): Add 'H' for
	canonical extension ordering based on current consensus.
---
 bfd/elfxx-riscv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
index 92ad03feea0..5c2c616a760 100644
--- a/bfd/elfxx-riscv.c
+++ b/bfd/elfxx-riscv.c
@@ -1345,7 +1345,7 @@ riscv_recognized_prefixed_ext (const char *ext)
 }
 
 /* Canonical order for single letter extensions.  */
-static const char riscv_ext_canonical_order[] = "eigmafdqlcbkjtpvn";
+static const char riscv_ext_canonical_order[] = "eigmafdqlcbkjtpvnh";
 
 /* Array is used to compare the orders of standard extensions quickly.  */
 static int riscv_ext_order[26] = {0};
-- 
2.34.1