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

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

[Tsukasa OI]

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

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

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