Making recently ratified RISC-V stuffs to 2.38: TODO list

[Nelson Chu]

Hi Tsukasa,

Thanks for the summary.  I think it is too late to commit these new
features since the binutils 2.38 release is really close.  We used to
commit some new features at the last minute before the release, but it
caused troubles that we needed to revert them and have a new release.
Therefore, it should not be a good idea to commit any new features for
now, but fixing bugs should be acceptable.  Personally, I plan to work
on and commit these recent patches after the 2.38 release, so we could
have a safer mainline and stable release.

Thanks
Nelson

On Sun, Jan 9, 2022 at 3:24 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
>
> Hi Nelson and all RISC-V guys,
>
> I'm working on several changes involving recently ratified extensions and
> I hope that most of recently ratified stuffs to be merged in GNU Binutils
> 2.38.  So, I will explain what is/isn't complete.
>
>
> *   Bit-Manipulation ISA-extensions (Zba/Zbb/Zbc/Zbs)
>     STATUS [UPSTREAM]: complete and merged into master
> *   Cryptography Extensions (Zk*)
>     STATUS [UPSTREAM]: complete and merged into master
> *   Vector Extension (V/Zv*)
>     STATUS [UPSTREAM]: complete and merged into master
> *   Floating point in integer registers, Part 1 (Zfinx/Zdinx/Zqinx)
>     STATUS [UPSTREAM]: complete and merged into master
> *   Cache-block Management Operations (Zicbom/Zicbop/Zicboz)
>     STATUS [COMPLETE]: my patchset is waiting for copyright assignment
> *   Privileged Architecture, version 1.12
>     (Sm1-12/Ss1-12/Sv57/H/Svinval/Svnapot/Svpbmt)
>     STATUS [REQUIRE_NEW_CSR]: complete except some new CSRs
>     [my patchset is pending for submission]
> *   PMP Enhancements (Smepmp)
>     STATUS [REQUIRE_NEW_CSR]: requires new CSRs in the Privileged Arch 1.12
>     [my patchset is pending for submission]
> *   Count Overflow and Mode-Based Filtering Extension (Sscofpmf)
>     STATUS [REQUIRE_NEW_CSR]: new extension and CSRs are required
>     [my patchset is pending for submission]
> *   State Enable Extension (Smstateen)
>     STATUS [REQUIRE_NEW_CSR]: new extension and CSRs are required
>     [my patchset is pending for submission]
> *   "stimecmp / vstimecmp" Extension (Sstc)
>     STATUS [REQUIRE_NEW_CSR]: new extension and CSRs are required
>     [my patchset is pending for submission]
> *   Half-precision floating point (Zfh/Zfhmin)
>     STATUS [REQUIRE_NEW_INSN]: new instructions must be implemented
>     [my patchset is pending for submission]
> *   Floating point in integer registers, Part 2 (Zhinx/Zhinxmin)
>     STATUS [REQUIRE_NEW_INSN]: Zfh/Zfhmin must be implemented
>
> Related (but still unstable) specification includes:
>
> *   Debug Specification, version 1.0
>     (Privileged Arch 1.12 lists Debug Specification 1.0 CSRs)
>     STATUS [COMPLETE]: a patchset by Nelson Chu is available[1]
>
> [1] <https://sourceware.org/pipermail/binutils/2021-August/117568.html>
> (will require complex rebase because of changes after the base commit)
>
>
> [TODO list]
>
> 1. Entries that my patchsets are pending
> 2. Debug Specification, version 1.0
> 3. Zhinx/Zhinxmin
>
>
> [TODO: Entries that my patchsets are pending]
>
> Except Zhinx/Zhinxmin, recently ratified stuffs are either complete or
> can be completed by my upcoming (almost complete) patchsets.  But if you
> (I mean anyone else) are working on the list above, I will recommend to
> submit yours first because my copyright assignment is not yet complete
> (I submitted the form in the last week and waiting for FSF approval).
>
> Another question is, am I okay to submit my pending patchsets (even if I
> know that copyright assignment to FSF is not done)?  I'm sure that I made
> my patchsets willing to be a part of GNU Binutils but I don't want to
> disrupt development of Binutils because of copyright concerns (**even
> temporarily**, considering tight schedule until 2.38 branch date).
>
> Anyway, I will submit my patchsets as soon as possible if my copyright
> assignment completes.
>
>
> [TODO: Debug Specification, version 1.0]
>
> Although this specification is not yet ratified, the Privileged
> Architecture version 1.12 lists CSRs as defined in the Debug Specification,
> version 1.0.
>
> Adding "hcontext" and "mscontext" CSRs would be safe but the real problem
> is "scontext".  This CSR is moved from 0x7aa to 0x5a8 (reflecting mode
> accessibility) in the latest debug specification (mirror of "scontext" is
> defined as "mscontext" with address 0x7aa, same as old "scontext").
>
> Those are "just" listed (Priv arch 1.12 has no mention of usecases of
> "scontext" and "mscontext") and **could** be ignored.
>
> But I'm not really sure.
>
>
> [TODO: Zhinx/Zhinxmin]
>
> They share the same opcodes as Zfh/Zfhmin and it "seems" it's ready for
> Binutils 2.38 ... but actually, it's not.
>
> The problem is we cannot determine right location to put "Zhinx"/
> "Zhinxmin" extension names (because "Z" extensions must be sorted by
> second character indicating extension category but 'h' [supposed to be
> hypervisor-related] is not on the category order list).
>
> This also applies to hypervisor instructions but seems implemented as a
> part of "I" extension instead of "H" [2].  That would be acceptable as a
> tentative workaround but the same cannot be applied to Zhinx/Zhinxmin
> because Zhinx/Zhinxmin conflict with "F" (basic floating point).
>
> [2] <https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a63375ac337>
>
> Considering specialized usecases of these extensions, I think the best
> option for Zhinx/Zhinxmin is to wait until correct order is determined by
> the specification.  What do you think?
>
>
>
> I hope this mail describes recent RISC-V status correctly and helps
> avoiding implementing the same extension multiple times.
>
> Thanks,
> Tsukasa