[PATCH 7/7] RISC-V: add zbb support to string functions

[Conor.Dooley at microchip.com]

On 25/11/2022 07:49, Andrew Jones wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, Nov 25, 2022 at 12:51:54AM +0100, Heiko Stuebner wrote:
>> Am Donnerstag, 24. November 2022, 23:32:58 CET schrieb Conor Dooley:
>>> On Thu, Nov 24, 2022 at 11:23:08PM +0100, Heiko Stübner wrote:
> ...
>>>>>> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
>>>>>> index bf9dd6764bad..66ff36a57e20 100644
>>>>>> --- a/arch/riscv/kernel/cpu.c
>>>>>> +++ b/arch/riscv/kernel/cpu.c
>>>>>> @@ -166,6 +166,7 @@ static struct riscv_isa_ext_data isa_ext_arr[] = {
>>>>>>        __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC),
>>>>>>        __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
>>>>>>        __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
>>>>>> +     __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
>>>>>>        __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM),
>>>>>>        __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
>>>>>>        __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX),
>>>>>
>>>>> This one I do know that Palmer wants canonically ordered.
>>>
>>> btw, idk if you noticed but I appear to have picked canonical ordering
>>> as today's thing to get confused about a lot.
>>>
>>> You put zbb after the S extentions - does that meant it is *not* an
>>> "Additional Standard Extension" but rather a regular Z one?
>>
>> This confuses me completely now :-) .
>>
> 
> Can we instead post a patch to the spec that changes the order to
> alphabetical? The only other option I see is to develop a tool which sorts
> extensions and every RISC-V developer keeps it in their back pocket. A
> kernel specific tool to check each list we want to keep sorted would be
> nice too.

Is there some reason that these things need to be output in canonical
order in the first place by the kernel?
Could we say to hell with even trying to figure out what the correct
order is (since yeah, it'll be a conversation ~every time this comes up)
or is that breaking uAPI since someone's parser in userland may expect to
see canonical order only?
That's been my assumption for why it was re-sorted, @Palmer?

> My preference would be to change the spec to alphabetical order, though,
> because the spec isn't explicit[*] enough to write a tool that can handle
> all cases. We'll end up needing to have conversations like this one to
> write the tool and eventually the tool will be what everyone looks to,
> rather than the spec...

If it could be explicitly clear what constitutes an "additional standard
extension" that'd be good enough for me! Say:

diff --git a/src/naming.tex b/src/naming.tex
index bfd67d4..9d63a86 100644
--- a/src/naming.tex
+++ b/src/naming.tex
@@ -80,7 +80,9 @@ Standard extensions can also be named using a single ``Z'' followed by an
  alphabetical name and an optional version number.  For example,
  ``Zifencei'' names the instruction-fetch fence extension described in
  Chapter~\ref{chap:zifencei}; ``Zifencei2'' and ``Zifencei2p0'' name version
-2.0 of same.
+2.0 of same. The entire set of Additional Standard Extensions are documented
+in the Standard Unprivileged Extensions section of Table~\ref{isanametable}
+below.
  
  The first letter following the ``Z'' conventionally indicates the most closely
  related alphabetical extension category, IMAFDQCVH.  For the ``Zam''