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

[Tsukasa OI]

Hi Nelson,

On 2022/01/11 17:54, Nelson Chu wrote:
> 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.

Understood.

I think adding new CSRs would be great (considering Binutils 2.38 will
have "Privileged Architecture 1.12 support") but not mandatory.

Anyway, safety first.  A few programs with my 'Zfh' / 'Zfhmin' patchset
is tested on the simulator but lacks full testsuite.  Delaying 'Zfh'
would make us time to make full testsuite (as well as ...surprisingly...
'F', 'D' and 'Q').

Thanks,
Tsukasa

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