Public Review for Zaamo and Zalrsc Standard Extensions

[Ved Shanbhogue]

Greetings!

We are delighted to announce the commencement of the public review
period for the Zaamo and Zalrsc Fast Track Extension specifications. 

The 30-day review period begins today, February 26, and concludes on

March 27. These specifications establish official extension names for 

these two parts of the ratified "A" extension. These extensions fall under

the Unprivileged Specification. 

The specification is available for download as a PDF here:
https://github.com/riscv/riscv-zaamo-zalrsc/releases/download/v1.0-rc2/riscv-zaamo-zalrsc.pdf 

This document originates from the source available in the GitHub
repository: https://github.com/riscv/riscv-zaamo-zalrsc

To respond to the public review, please either email comments to the
public RISC-V ISA-Dev mailing list at isa...@groups.riscv.org or add
issues to the GitHub repo: https://github.com/riscv/riscv-zaamo-zalrsc/issues

Should you encounter any issues accessing the document or the GitHub
links, please do not hesitate to contact us. We are eager to provide
assistance or furnish the document in an alternative format upon request.

We value all feedback and appreciate your contribution toward refining
this specification.

Throughout the public review period, we will collect corrections,
comments, and suggestions for consideration by the Unprivileged ISA
Committee. Minor corrections and/or non-controversial changes will be
incorporated into the specification directly. Any unresolved issues or
proposed modifications will be detailed in the public review summary
report. Assuming no issues necessitate incompatible changes to the
specification under review, the Unprivileged ISA Committees will 

propose that the updated specifications be ratified by both the RISC-V

Technical Steering Committee and the RISC-V Board of Directors.

We extend our gratitude to all contributors for their dedicated
efforts.

Regards,
Ved Shanbhogue

[BGB]

On 2/26/2024 9:10 AM, Ved Shanbhogue wrote:
> Greetings!
>
> We are delighted to announce the commencement of the public review
> period for the Zaamo and Zalrsc Fast Track Extension specifications.
> The 30-day review period begins today, February 26, and concludes on
> March 27. These specifications establish official extension names for
> these two parts of the ratified "A" extension. These extensions fall under
> the Unprivileged Specification.
>
> The specification is available for download as a PDF here:

> https://github.com/riscv/riscv-zaamo-zalrsc/releases/download/v1.0-rc2/riscv-zaamo-zalrsc.pdf <https://github.com/riscv/riscv-zaamo-zalrsc/releases/download/v1.0-rc2/riscv-zaamo-zalrsc.pdf>

>
> This document originates from the source available in the GitHub
> repository: https://github.com/riscv/riscv-zaamo-zalrsc
> <https://github.com/riscv/riscv-zaamo-zalrsc>
>
> To respond to the public review, please either email comments to the
> public RISC-V ISA-Dev mailing list at isa...@groups.riscv.org

> <mailto:isa...@groups.riscv.org> or add

> issues to the GitHub repo:
> https://github.com/riscv/riscv-zaamo-zalrsc/issues
> <https://github.com/riscv/riscv-zaamo-zalrsc/issues>
>
> Should you encounter any issues accessing the document or the GitHub
> links, please do not hesitate to contact us. We are eager to provide
> assistance or furnish the document in an alternative format upon request.
>
> We value all feedback and appreciate your contribution toward refining
> this specification.
>

So, looks like taking the 'A' extension and breaking it into two
subparts? Makes sense enough to me. I guess if one implements both, the
just claim the 'A' extension as usual?...

Looks fine by me, in any case.

> Throughout the public review period, we will collect corrections,
> comments, and suggestions for consideration by the Unprivileged ISA
> Committee. Minor corrections and/or non-controversial changes will be
> incorporated into the specification directly. Any unresolved issues or
> proposed modifications will be detailed in the public review summary
> report. Assuming no issues necessitate incompatible changes to the
> specification under review, the Unprivileged ISA Committees will
> propose that the updated specifications be ratified by both the RISC-V
> Technical Steering Committee and the RISC-V Board of Directors.
>
> We extend our gratitude to all contributors for their dedicated
> efforts.
>

As I can note, my wish-list for extensions still looks something like:
Register indexed load/store;
For implementations that don't want 3-input integer ops,
they can skip/ignore this extension.
Bigger intermediate-sized constants
Say, ability to load 17 bits in a single 1-cycle instruction.
Maybe an F/D subset that makes FDIV/FSQRT/FMADD/etc, optional (*1).
Like in Zfinx/Zdinx, but maybe still allowing use of FPRs.

*1: Or, at least maybe a more convenient way to tell GCC not to use
these features (say, if they are absent and/or give "boat anchor"
performance in a given implementation).

Maybe the encodings where LDU/SDU would be, could be defined as a
Load-Pair / Store-Pair for RV64.


While Zba (SHnADD) does at least reduce the pain from the lack of
register-indexed load/store, it does not entirely eliminate it.

This is mostly for cases which seem to limit performance more than ideal.


Granted, these would almost be self-defeating in my case, since if
RISC-V could match the performance of my ISA (at least on my
implementation), it would call into question the usefulness of my own ISA.

Though, this is more a question of if Doom can be made roughly 20%
faster in RV64 (for Dhrystone and Software Quake, it seems to be roughly
break-even at this point).

After adding superscalar decoding, Dhrystone was temporarily in the lead
with RV64, but my ISA regained the lead by re-enabling the use of
branch-and-compare ops, and telling my compiler not to use stack canary
checks. Both seem currently break-even at present in this case (both
roughly 90k ATM, ~ 1.02 DMIPS/MHz; executing roughly 35 MIPs at 50 MHz
in terms of actual ISA instructions).


...


> Regards,
> Ved Shanbhogue
>
> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to isa-dev+u...@groups.riscv.org
> <mailto:isa-dev+u...@groups.riscv.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG5apL3_kv-Pgjuv3-3pN7gQ%2BPxq%2BU%3DwuinWuL5ZkaGTZY91Yg%40mail.gmail.com <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG5apL3_kv-Pgjuv3-3pN7gQ%2BPxq%2BU%3DwuinWuL5ZkaGTZY91Yg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Ved Shanbhogue]

BGB wrote:
>So, looks like taking the 'A' extension and breaking it into two
>subparts? Makes sense enough to me. I guess if one implements both,
>the just claim the 'A' extension as usual?...

That is correct.

>As I can note, my wish-list for extensions still looks something like:
> Register indexed load/store;
> For implementations that don't want 3-input integer ops,
> they can skip/ignore this extension.
> Bigger intermediate-sized constants
> Say, ability to load 17 bits in a single 1-cycle instruction.
> Maybe an F/D subset that makes FDIV/FSQRT/FMADD/etc, optional (*1).
> Like in Zfinx/Zdinx, but maybe still allowing use of FPRs.

Some of these have been discussed in various contexts before. There is
a Combined Instructions SIG in inception that plans to work on these
topics: https://github.com/riscv-admin/riscv-combined-instructions

regards
ved

[BGB]

On 2/27/2024 4:00 PM, Ved Shanbhogue wrote:
> BGB wrote:
>> So, looks like taking the 'A' extension and breaking it into two
>> subparts? Makes sense enough to me. I guess if one implements both,
>> the just claim the 'A' extension as usual?...
>
> That is correct.
>

OK, makes sense.

>> As I can note, my wish-list for extensions still looks something like:
>>  Register indexed load/store;
>>    For implementations that don't want 3-input integer ops,
>>      they can skip/ignore this extension.
>>  Bigger intermediate-sized constants
>>    Say, ability to load 17 bits in a single 1-cycle instruction.
>>  Maybe an F/D subset that makes FDIV/FSQRT/FMADD/etc, optional (*1).
>>    Like in Zfinx/Zdinx, but maybe still allowing use of FPRs.
>
> Some of these have been discussed in various contexts before. There is
> a Combined Instructions SIG in inception that plans to work on these
> topics: https://github.com/riscv-admin/riscv-combined-instructions
>

Yes, that is good.


I suspect probably register-indexed load/store and bigger immediate
loads could help a fair bit (and are probably the main ones effecting
performance).

I guess, one could also try to make a case for auto-increment
addressing, but I had skipped it in my ISA mostly because it is ugly to
deal with (and was comparably less common).

I guess, roughly half the items on the charter are things that are
absent in my ISA as well.

...



> regards
> ved