Public review for standard extensions Zilsd & Zclsd

309 views
Skip to first unread message

Christian Herber

unread,
Nov 14, 2024, 2:56:43 PM11/14/24
to isa...@groups.riscv.org
We are delighted to announce the start of the public review period for the following proposed standard extensions to the RISC-V ISA:


Zilsd: Load/Store Pair for RV32
Zclsd: Load/Store Pair for RV32 (compressed)


The review period begins today, 14th Nov, and ends on 13th Dec (inclusive).


This extension is part of the Unprivileged Specification.


These extensions are described in the PDF spec available at:




which was generated from the source available in the following GitHub repo:




To respond to the public review, please either email comments to the public isa-dev mailing list or add issues and/or pull requests (PRs) to the GitHub repo: https://github.com/riscv/riscv-zilsd/issues. We welcome all input and appreciate your time and effort in helping us by reviewing the specification.


During the public review period, corrections, comments, and suggestions, will be gathered for review. Any minor corrections and/or uncontroversial changes will be incorporated into the specification. Any remaining issues or proposed changes will be addressed in the public review summary report. If there are no issues that require incompatible changes to the public review specification, the Unprivileged ISA Committee will recommend the updated specifications be approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors.


Thanks to all the contributors for all their hard work.


Christian Herber

Owner of the Load/Store Pair for RV32 fast-track extension


BGB

unread,
Nov 14, 2024, 6:14:09 PM11/14/24
to isa...@groups.riscv.org
On 11/14/2024 1:56 PM, Christian Herber wrote:
> We are delighted to announce the start of the public review period for
> the following proposed standard extensions to the RISC-V ISA:
>
>
> Zilsd: Load/Store Pair for RV32
> Zclsd: Load/Store Pair for RV32 (compressed)
>

This reminds me of something...


Maybe it might make sense to define an extension, say:
The LQ and SQ encodings can be understood as Load/Store Pair on RV64.

Or, at least, this is something (among other things) that I am doing in
my own non-standard implementation.

Also, FLQ and FSQ for Load/Store Pair to the F registers (when FLEN=64).


Basically, same basic idea, just for RV64.


AFAIK, there is not presently any formal proposals for 64-bit Load/Store
Pair.

Or, say, as a possible RV64 version of Zilsd?...



>
> The review period begins today, 14th Nov, and ends on 13th Dec (inclusive).
>
>
> This extension is part of the Unprivileged Specification.
>
>
> These extensions are described in the PDF spec available at:
>
>
> https://github.com/riscv/riscv-zilsd/releases/download/v1.0-rc1/riscv-
> zilsd-v1.0-rc1.pdf
>
>
> which was generated from the source available in the following GitHub repo:
>
>
> https://github.com/riscv/riscv-zilsd/blob/main/zilsd.adoc
>

Makes sense to me...

No particular comment otherwise, except that it can help with code
density and performance, so no strong reason to not have it.

Except maybe in smaller microcontrollers (where cost optimization is
likely the main priority).




In other news (unrelated), for my own thing, I am tempted to move my
"jumbo prefixes" to a different part of the encoding space.

Current:
* jiiiiii-iiiii-jjjjj-100-kkkkk-00-11011 J21
* 0iiiiii-iiiii-jjjjj-100-kkkkk-00-11011 J21_IMM
* 1iiiiii-iiiii-zzzzz-100-omnpp-00-11011 J21_OP

This conflicts with an ADDIWU instruction that existed in an earlier
version of BitManip, but has since been removed. I didn't notice this
when I was looking for an encoding to use, but it could matter if
someone did actually want to re-add ADDIWU (I am on the fence, as I see
it the improvements to code density and performance due to these
prefixes is larger than that which would have been given by an ADDIWU
instruction; though, for my own uses, I did re-add ADDWU and SUBWU).

Also, where it is now currently results in an ugly hack in my
superscalar handling code. But, OTOH, this may not matter as much if one
assumes ADDIWU isn't coming back.



Possible new encoding:
* jiiiiii-iiiii-jjjjj-100-kkkkk-11-00111 J21_NEW
* 0iiiiii-iiiii-jjjjj-100-kkkkk-11-00111 J21_IMM_NEW
* 1iiiiii-iiiii-zzzzz-100-omnpp-11-00111 J21_OP_NEW

This would put it in the same block as JALR. Best I can tell, by my own
gathered lists, there is nothing else here. I could then phase out the
existing encodings.


Also wanting to define an encoding to load a 64-bit value into F0..F31.

Where, in the existing scheme:
"J21 + J21 + LUI": Loads a 64-bit value into Xn, no bits left over.
"J21 + J21 + AUIPC": Maybe loads 64b into F0..F31 ?...
These combinations using 96 bits / 12-bytes of space.

I still consider these 96-bit cases as optional, as they imply a wider
fetch and more complexity than needed for 64-bit encodings (say, loading
a 64-bit value in two 64-bit encodings; eating 16 bytes of space, and
around 2 clock cycles in my implementation; vs 1 clock cycle for a
96-bit encoding).

As noted, as-is:
J21_IMM + 3R_Imm12 operations extends immediate to 33 bits;
Can be applied to all existing Imm12 or Disp12 instructions.
J21 + 3R operations may synthesize an immediate for some ops;
Say, for example, MULW lacking an immediate form, etc.
J21 + LUI: Encodes a 33-bit (sign-extended) constant load (*1).
J21 + AUIPC: Encodes a 33-bit PC+Disp (*1).
*1: The remaining bits in the prefix left as more encoding space.
For LUI, encodings also allow loading a 32-bit value into F0..F31.
Base instruction gives high 20 bits of Imm/Disp;
Prefix gives the low 12 bits, and a sign-extension bit.
J21 + JAL: Extends branch displacement to 33 bits.
Though, the displacement is decoded same as AUIPC in this case.
Existing JAL displacement encoding is nightmarish...
Using the same format as J21_AUIPC allows reusing the same reloc.


Granted, I still don't really expect that anyone else would likely adopt
any of this (and probably wouldn't see so much direct use by
applications), but I do still see good results (regarding code density
and performance) in my own testing (and still seems relevant to tasks
like "make OpenGL and similar faster").

Ignoring a few other (more aggressive) experiments at the moment...


>
> To respond to the public review, please either email comments to the
> public isa-dev mailing list or add issues and/or pull requests (PRs) to
> the GitHub repo: https://github.com/riscv/riscv-zilsd/issues. We welcome
> all input and appreciate your time and effort in helping us by reviewing
> the specification.
>
>
> During the public review period, corrections, comments, and suggestions,
> will be gathered for review. Any minor corrections and/or
> uncontroversial changes will be incorporated into the specification. Any
> remaining issues or proposed changes will be addressed in the public
> review summary report. If there are no issues that require incompatible
> changes to the public review specification, the Unprivileged ISA
> Committee will recommend the updated specifications be approved and
> ratified by the RISC-V Technical Steering Committee and the RISC-V Board
> of Directors.
>
>
> Thanks to all the contributors for all their hard work.
>
>
> Christian Herber
>
> Owner of the Load/Store Pair for RV32 fast-track extension
>
>
> --
> 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+uns...@groups.riscv.org>.
> To view this discussion visit https://groups.google.com/a/
> groups.riscv.org/d/msgid/isa-dev/
> GV1PR04MB95136F374F294D9CAFDEA865865B2%40GV1PR04MB9513.eurprd04.prod.outlook.com <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/GV1PR04MB95136F374F294D9CAFDEA865865B2%40GV1PR04MB9513.eurprd04.prod.outlook.com?utm_medium=email&utm_source=footer>.

Christian Herber

unread,
Nov 14, 2024, 8:27:56 PM11/14/24
to BGB, isa...@groups.riscv.org
The LQ and SQ instructions do not have an encoding. 

Load/store pair instructions also for RV64 is something that is being considered in the scalar efficiency SIG.

From: BGB <cr8...@gmail.com>
Sent: Thursday, November 14, 2024 8:13:52 PM
To: isa...@groups.riscv.org <isa...@groups.riscv.org>
Subject: [EXT] Re: [isa-dev] Public review for standard extensions Zilsd & Zclsd
 
[You don't often get email from cr8...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button



On 11/14/2024 1:56 PM, Christian Herber wrote:
> We are delighted to announce the start of the public review period for
> the following proposed standard extensions to the RISC-V ISA:
>
>
> Zilsd: Load/Store Pair for RV32
> Zclsd: Load/Store Pair for RV32 (compressed)
>

This reminds me of something...


Maybe it might make sense to define an extension, say:
   The LQ and SQ encodings can be understood as Load/Store Pair on RV64.

Or, at least, this is something (among other things) that I am doing in
my own non-standard implementation.

Also, FLQ and FSQ for Load/Store Pair to the F registers (when FLEN=64).


Basically, same basic idea, just for RV64.


AFAIK, there is not presently any formal proposals for 64-bit Load/Store
Pair.

Or, say, as a possible RV64 version of Zilsd?...



>
> The review period begins today, 14th Nov, and ends on 13th Dec (inclusive).
>
>
> This extension is part of the Unprivileged Specification.
>
>
> These extensions are described in the PDF spec available at:
>
>

> zilsd-v1.0-rc1.pdf
>
>
> which was generated from the source available in the following GitHub repo:
>
>

> all input and appreciate your time and effort in helping us by reviewing
> the specification.
>
>
> During the public review period, corrections, comments, and suggestions,
> will be gathered for review. Any minor corrections and/or
> uncontroversial changes will be incorporated into the specification. Any
> remaining issues or proposed changes will be addressed in the public
> review summary report. If there are no issues that require incompatible
> changes to the public review specification, the Unprivileged ISA
> Committee will recommend the updated specifications be approved and
> ratified by the RISC-V Technical Steering Committee and the RISC-V Board
> of Directors.
>
>
> Thanks to all the contributors for all their hard work.
>
>
> Christian Herber
>
> Owner of the Load/Store Pair for RV32 fast-track extension
>
>
> --
> 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+uns...@groups.riscv.org>.
> To view this discussion visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2F&data=05%7C02%7Cchristian.herber%40nxp.com%7Cef0e824bb54445afe92d08dd05020b7c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638672228532625227%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=AqB%2FQAOQXLKbG7LiEas9MK0PdJPn4TIB43OImGqZxLQ%3D&reserved=0
> groups.riscv.org/d/msgid/isa-dev/
> GV1PR04MB95136F374F294D9CAFDEA865865B2%40GV1PR04MB9513.eurprd04.prod.outlook.com <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fgroups.riscv.org%2Fd%2Fmsgid%2Fisa-dev%2FGV1PR04MB95136F374F294D9CAFDEA865865B2%2540GV1PR04MB9513.eurprd04.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C02%7Cchristian.herber%40nxp.com%7Cef0e824bb54445afe92d08dd05020b7c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638672228532636842%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=1%2Bq761niFUTvdWOqpobzJApj4WpF6YB2qZs0f3MZ060%3D&reserved=0>.


--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

BGB

unread,
Nov 15, 2024, 8:33:46 AM11/15/24
to Christian Herber, isa...@groups.riscv.org
On 11/14/2024 7:27 PM, Christian Herber wrote:
> The LQ and SQ instructions do not have an encoding.
>
> Load/store pair instructions also for RV64 is something that is being
> considered in the scalar efficiency SIG.
>

OK, seems so.

I had somehow thought they did already have an encoding.


Admittedly, in my implementation, for Load/Store Pair, I had used:
* iiiiiii-iiiii-mmmmm-111-nnnnn-00-00011 LX Rn, Disp12_I(Rm)
* iiiiiii-ttttt-mmmmm-111-iiiii-01-00011 SX Rt, Disp12_S(Rm)

With LX/SX as the pair ops.

So, using LDU for the Load-Pair, but LDU otherwise does not make sense
on a 64-bit machine. But, as noted, all this is a bit, unofficial...



From what I could gather (for LQ/SQ):
* iiiiiii-iiiii-mmmmm-111-nnnnn-00-00011 LDU Rn, Disp12_I(Rm)
* iiiiiii-ttttt-mmmmm-100-iiiii-01-00011 SQ Rt, Disp12_S(Rm)
* iiiiiii-iiiii-mmmmm-111-nnnnn-00-01111 LQ Rn, Disp12_I(Rm)


I could change things if needed...
But, there was some amount of inertia, so...

Sort of figured people would likely use LQ/SQ if doing it standard, but
somehow I had thought these had already been defined somewhere.

...



> ------------------------------------------------------------------------
> *From:* BGB <cr8...@gmail.com>
> *Sent:* Thursday, November 14, 2024 8:13:52 PM
> *To:* isa...@groups.riscv.org <isa...@groups.riscv.org>
> *Subject:* [EXT] Re: [isa-dev] Public review for standard extensions
> Zilsd & Zclsd
> [You don't often get email from cr8...@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification <https://
> aka.ms/LearnAboutSenderIdentification> ]
>
> Caution: This is an external email. Please take care when clicking links
> or opening attachments. When in doubt, report the message using the
> 'Report this email' button
>
>
> On 11/14/2024 1:56 PM, Christian Herber wrote:
>> We are delighted to announce the start of the public review period for
>> the following proposed standard extensions to the RISC-V ISA:
>>
>>
>> Zilsd: Load/Store Pair for RV32
>> Zclsd: Load/Store Pair for RV32 (compressed)
>>
>
> This reminds me of something...
>
>
> Maybe it might make sense to define an extension, say:
>    The LQ and SQ encodings can be understood as Load/Store Pair on RV64.
>
> Or, at least, this is something (among other things) that I am doing in
> my own non-standard implementation.
>
> Also, FLQ and FSQ for Load/Store Pair to the F registers (when FLEN=64).
>
>
> Basically, same basic idea, just for RV64.
>
>
> AFAIK, there is not presently any formal proposals for 64-bit Load/Store
> Pair.
>
> Or, say, as a possible RV64 version of Zilsd?...
>
>
>
>>
>> The review period begins today, 14th Nov, and ends on 13th Dec (inclusive).
>>
>>
>> This extension is part of the Unprivileged Specification.
>>
>>
>> These extensions are described in the PDF spec available at:
>>
>>
>> https://eur01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-
> zilsd%2Freleases%2Fdownload%2Fv1.0-rc1%2Friscv-
> &data=05%7C02%7Cchristian.herber%40nxp.com%7Cef0e824bb54445afe92d08dd05020b7c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638672228532577622%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=XA9LUVoUn23OgmXxwHy8p8xoHqFy1v7U1FUHLcv5Go4%3D&reserved=0 <https://github.com/riscv/riscv-zilsd/releases/download/v1.0-rc1/riscv->
>> zilsd-v1.0-rc1.pdf
>>
>>
>> which was generated from the source available in the following GitHub repo:
>>
>>
>> https://eur01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-
> zilsd%2Fblob%2Fmain%2Fzilsd.adoc&data=05%7C02%7Cchristian.herber%40nxp.com%7Cef0e824bb54445afe92d08dd05020b7c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638672228532597063%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Yy6yw2KnvHjIYUD0IAtb6gIJ9wXdXao74V6bnznVwIM%3D&reserved=0 <https://github.com/riscv/riscv-zilsd/blob/main/zilsd.adoc>
> zilsd%2Fissues&data=05%7C02%7Cchristian.herber%40nxp.com%7Cef0e824bb54445afe92d08dd05020b7c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638672228532611221%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=pWOnD0gIkPvolLDo6VbzN8SY1ZXYzWMMNC68rzHQnpQ%3D&reserved=0 <https://github.com/riscv/riscv-zilsd/issues>. We welcome
>> all input and appreciate your time and effort in helping us by reviewing
>> the specification.
>>
>>
>> During the public review period, corrections, comments, and suggestions,
>> will be gathered for review. Any minor corrections and/or
>> uncontroversial changes will be incorporated into the specification. Any
>> remaining issues or proposed changes will be addressed in the public
>> review summary report. If there are no issues that require incompatible
>> changes to the public review specification, the Unprivileged ISA
>> Committee will recommend the updated specifications be approved and
>> ratified by the RISC-V Technical Steering Committee and the RISC-V Board
>> of Directors.
>>
>>
>> Thanks to all the contributors for all their hard work.
>>
>>
>> Christian Herber
>>
>> Owner of the Load/Store Pair for RV32 fast-track extension
>>
>>
>> --
>> 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+uns...@groups.riscv.org>.
>> To view this discussion visit https://eur01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgroups.google.com%2Fa%2F&data=05%7C02%7Cchristian.herber%40nxp.com%7Cef0e824bb54445afe92d08dd05020b7c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638672228532625227%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=AqB%2FQAOQXLKbG7LiEas9MK0PdJPn4TIB43OImGqZxLQ%3D&reserved=0 <https://groups.google.com/a/>
>> groups.riscv.org/d/msgid/isa-dev/
>> GV1PR04MB95136F374F294D9CAFDEA865865B2%40GV1PR04MB9513.eurprd04.prod.outlook.com <https://eur01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgroups.google.com%2Fa%2Fgroups.riscv.org%2Fd%2Fmsgid%2Fisa-dev%2FGV1PR04MB95136F374F294D9CAFDEA865865B2%2540GV1PR04MB9513.eurprd04.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C02%7Cchristian.herber%40nxp.com%7Cef0e824bb54445afe92d08dd05020b7c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638672228532636842%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=1%2Bq761niFUTvdWOqpobzJApj4WpF6YB2qZs0f3MZ060%3D&reserved=0 <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/GV1PR04MB95136F374F294D9CAFDEA865865B2%40GV1PR04MB9513.eurprd04.prod.outlook.com?utm_medium=email&utm_source=footer>>.
>
> --
> 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.
> To view this discussion visit https://
> eur01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgroups.google.com%2Fa%2Fgroups.riscv.org%2Fd%2Fmsgid%2Fisa-dev%2F1ad13b25-1fc0-4f76-92a3-1dbf4d0784d6%2540gmail.com&data=05%7C02%7Cchristian.herber%40nxp.com%7Cef0e824bb54445afe92d08dd05020b7c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638672228532647648%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=Te5F8OiK998ggTuENuCuF%2BVqlpNPu4CBAFuKfH8rlrA%3D&reserved=0 <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/1ad13b25-1fc0-4f76-92a3-1dbf4d0784d6%40gmail.com>.

Dan Petrisko

unread,
Nov 15, 2024, 8:33:52 AM11/15/24
to Christian Herber, BGB, isa...@groups.riscv.org
Hi,

Thanks for great work! 

Are there GCC/LLVM/binutils implementations publicly available? Latest I found was: https://lists.riscv.org/g/tech-unprivileged/topic/zilsd_load_store_pair_for/104924477

Best,
-Dan

To view this discussion visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/GV1PR04MB9513B292166FF62BAAF29C2D86242%40GV1PR04MB9513.eurprd04.prod.outlook.com.

Christian Herber

unread,
Nov 15, 2024, 8:41:10 AM11/15/24
to Dan Petrisko, BGB, isa...@groups.riscv.org
Yes, there are prototypes for both.
I would recommend to start with my Summit presentation https://youtu.be/BCPsgt53OsI?si=PTIi8ZgROgIkPBP7

Links to all SW pieces can be found in the jira https://lf-riscv.atlassian.net/browse/RVS-1948

From: Dan Petrisko <petr...@cs.washington.edu>
Sent: Friday, November 15, 2024 2:08:45 AM
To: Christian Herber <christia...@nxp.com>
Cc: BGB <cr8...@gmail.com>; isa...@groups.riscv.org <isa...@groups.riscv.org>
Subject: Re: [EXT] Re: [isa-dev] Public review for standard extensions Zilsd & Zclsd
 

Iztok Jeras

unread,
Nov 15, 2024, 11:16:41 AM11/15/24
to RISC-V ISA Dev, Christian Herber
Ciao,

I see 2 x XLEN  instructions as a good fit for simple single issue in order processors also implementing the P extension.
The processor could have a 64-bit data memory interface, so LD/SD would double the memory access throughput.

LD/SD instructions could be used to implement atomic access to memory mapped 64-bit counters/timers, GPIO controllers, ...
The specification does not define a method for stating whether 64-bit aligned accesses are atomic or not,
so what would be the best way to write portable SW for timer/counter drivers, which would detect the presence of this atomicity.

In the same sense there could be double word CSR access instructions, which would simplify access to 64-bit CSR timer/counter registers.

Multiplication/division instructions writing into register pairs could also be considered.

Iztok Jeras

Torbjørn Viem Ness

unread,
Nov 17, 2024, 9:35:07 AM11/17/24
to RISC-V ISA Dev, BGB
> Maybe it might make sense to define an extension, say:
> The LQ and SQ encodings can be understood as Load/Store Pair on RV64.
>
> Or, at least, this is something (among other things) that I am doing in my own non-standard implementation.
>
> Also, FLQ and FSQ for Load/Store Pair to the F registers (when FLEN=64).
>
>
> Basically, same basic idea, just for RV64.
>
>
> AFAIK, there is not presently any formal proposals for 64-bit Load/Store Pair.
>
> Or, say, as a possible RV64 version of Zilsd?...

This was actually considered early on, but dropped because there was no defined LQ and SQ (RV128) encodings (among other reasons), and it would've made it much harder to reach he initial goal (64 bit memory ops on RV32) within a reasonable time frame.
See original spec discussion in this issue: https://github.com/tovine/riscv-rv32zild/issues/6

BGB

unread,
Nov 17, 2024, 6:02:45 PM11/17/24
to Torbjørn Viem Ness, RISC-V ISA Dev
On 11/17/2024 8:35 AM, Torbjørn Viem Ness wrote:
> > Maybe it might make sense to define an extension, say:
> > The LQ and SQ encodings can be understood as Load/Store Pair on RV64.
> >
> > Or, at least, this is something (among other things) that I am doing
> in my own non-standard implementation.
> >
> > Also, FLQ and FSQ for Load/Store Pair to the F registers (when FLEN=64).
> >
> >
> > Basically, same basic idea, just for RV64.
> >
> >
> > AFAIK, there is not presently any formal proposals for 64-bit Load/
> Store Pair.
> >
> > Or, say, as a possible RV64 version of Zilsd?...
>
> This was actually considered early on, but dropped because there was no
> defined LQ and SQ (RV128) encodings (among other reasons), and it
> would've made it much harder to reach he initial goal (64 bit memory ops
> on RV32) within a reasonable time frame.
> See original spec discussion in this issue: https://github.com/tovine/
> riscv-rv32zild/issues/6
>

Yeah, seems so.
I had thought they were defined, but seems what I found was unofficial.

I may modify my idea, either (what I currently use in my case):
* iiiiiii-iiiii-mmmmm-111-nnnnn-00-00011 LDP Rn, Disp12_I(Rm)
* iiiiiii-ttttt-mmmmm-111-iiiii-01-00011 SDP Rt, Disp12_S(Rm)


Or, alternatively:
* iiiiiii-iiiii-mmmmm-111-nnnnn-00-00011 LDP Rn, Disp12_I(Rm)
* iiiiiii-ttttt-mmmmm-100-iiiii-01-00011 SDP Rt, Disp12_S(Rm)

Say, LDU and the informal SQ encoding.



Decided to leave off going into other topics.


Could post a link to my project on GitHub, but I suspect probably people
here would not find it particularly relevant (might be slightly more
relevant if my core ran RV64 as the primary ISA).

It is possible to get it to boot into an RV64 OS image, but all the
supervisor-mode stuff differs from existing RV64 implementations. It
does not yet implement any of the privileged spec stuff, nor any
conventional hardware interfaces. Could address this, or maybe consider
a new/modified core that is more closely aligned to the RV use-case
(well, also running multiple ISA's possibly isn't ideal for LUT cost).
Not entirely obvious the best way forward.


<snip>

Christian Herber

unread,
Dec 13, 2024, 5:30:11 PM12/13/24
to isa...@groups.riscv.org, tech-announce

The public review is complete. Thanks to everybody who participated.

 

The following were the primary issues raised during public review of Zilsd and Zclsd extensions:

  1. Atomic LD writeback requirement is expensive for small cores: As a consequence of this issue, the requirement for atomic writeback into the destination pair registers was relaxed while maintaining the interruptibility. The change was approved by the ARC
  2. Unclarity about whether load/store pair are interruptible or not: It was clarified that instruction may still be implemented in an interruptible way. No changes to the specification were made.
  3. Load/store pair for RV64: It was raised, that LQ/SQ encodings could be used for Load/store pair for RV32. It was explained, that this is outside of the scope of this fast-track and that LQ/SQ encodings are not actually assigned. Load/store pair for RV64 will be a topic covered by the Scalar Efficiency SIG.
  4. Order of accesses: A question was raised on the order of accesses. The specification explicitly does not prescribe an order. Also in light of (1), flexibility in the ordering will be needed to reduce implementation cost and keep the sequence interruptible. Implementations are still expected to be deterministic in the order (at least given a concrete src and dst combination), but the specification does not have a strict requirement for that. It should be noted that e.g. for Zcmp, there is also no requirement on the byte ordering during a push or pop instruction.

 

A new release has been created, which incorporates the changes mentioned in (1).

Release: https://github.com/riscv/riscv-zilsd/releases/tag/v1.0-rc3

PDF: https://github.com/riscv/riscv-zilsd/releases/download/v1.0-rc3/riscv-zilsd-v1.0-rc3.pdf

 

Christian

Reply all
Reply to author
Forward
0 new messages