Re: Public review of RISC-V Zicond conditional zeroing extension

[Krste Asanovic]

[Resend with correct isa-dev address]

> On Apr 20, 2023, at 8:12 PM, Krste Asanovic <kr...@sifive.com> wrote:
>
>
> We are delighted to announce the start of the public review period for the
> following proposed Fast Track extensions to the RISC-V ISA:
>
> Zicond
>
> The review period begins today, April 20, 2023 and ends on March 21,
> 2023 (inclusive). Note the RISC-V BoD has approved reducing the
> minimum public review period to 30 days.
>
> This extension is part of the Unprivileged Specification and is
> described in the PDF spec available at:
>
> https://github.com/riscv/riscv-zicond/releases/download/v1.0-rc2/riscv-zicond-v1.0-rc2.pdf
>
> which was generated from the source available in the following GitHub repo:
>
> https://github.com/riscv/riscv-isa-manualhttps://github.com/riscv/riscv-isa-manual
>
> To respond to the public review, please either email comments to the public
> isa-dev mailing list, or add issues and/or pull requests to the RISC-V
> ISA Manual GitHub repo:
>
> https://github.com/riscv/riscv-isa-manual
>
> 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 by the Unprivileged ISA
> Committee. 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.
>
> Krste Ananović
> Chair, Unprivileged ISA Committee
>
> Earl Killian
> Vice-chair, Unprivileged ISA Committee
>

[Jeff Scheel]

>  The review period begins today, April 20, 2023 and ends on March 21,
>  2023 (inclusive).

The review will run through May 21, not March 21 as noted.  Sorry for any confusion.

-Jeff

--

Jeff Scheel (he/him/his)

Linux Foundation, RISC-V Technical Program Manager

--
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 on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/E1E89BB0-BDFB-483A-A836-1A44973A3ED9%40sifive.com.

[Andrea Parri]

The descriptions of czero in sections 3.1 and 3.2:

"Accordingly, the syntactic dependency on rs1 is only propagated
when the condition is false."

effectively makes the notion of dependency "depend" on a runtime state;
in other words, it makes that notion non-"syntactic" (e.g. [1]).

Unprivileged spec, section 17.3 lists similar "exceptions", should such
section/tables be updated to reflect the addition of the instruction at
stake?

Andrea

[1] From the commentary in Appendix A:

"[...] the RVWMO memory model uses syntactic rather than semantic
dependencies. [...] this definition depends on the identities of
the registers being accessed by different instructions, not the
actual contents of those registers."

[Rogier Brussee]

Hello 

Forgive me  for being  naive, but these instructions are motivated by reducing pressure on branch prediction. 

The two instructions should also be very easy to implement in hardware

e.g

 

czero.eq rd rs1 rs2 -->

mask = (rs2 == 0)? (~0) : 0;

rd = rs1 & mask

which is lone xlen wide  NOR port on rs1 fed to  xlen AND ports, one for each bit of  rs2.

What is the rationale for not making this a simple constant time (1 cycle)  integer/bit instruction  that can be scheduled just like ADD or OR, and which has the added

benefit of the instructions being useful for cryptography. 

Otherwise I think they are nice instructions:  e.g. they implement  boolean & !x or boolean & !!x 

Best

Rogier

Op vrijdag 21 april 2023 om 17:37:57 UTC+3 schreef Andrea Parri:

[Philipp Tomsich]

Rogier,

On Mon, 24 Apr 2023 at 10:14, Rogier Brussee <rogier....@gmail.com> wrote:
>
> Hello
>
> Forgive me for being naive, but these instructions are motivated by reducing pressure on branch prediction.
> The two instructions should also be very easy to implement in hardware
> e.g
>
> czero.eq rd rs1 rs2 -->
> mask = (rs2 == 0)? (~0) : 0;
> rd = rs1 & mask
>
> which is lone xlen wide NOR port on rs1 fed to xlen AND ports, one for each bit of rs2.
> What is the rationale for not making this a simple constant time (1 cycle) integer/bit instruction that can be scheduled just like ADD or OR, and which has the added
> benefit of the instructions being useful for cryptography.

These instructions subsume the functionality of a set + neg + and
instruction, eliminating the need for a temporary register:
e.g., czero.eq rd, rs1, rs2 :=
snez rtmp, rs2
neg rtmp, rtmp
and rd, rs1, rtmp
Given that no temporary is needed and most conditional-op sequences
(e.g., conditional-add) are 2-instruction long, this makes such
conditional sequences suitable for macro-fusion.
So the benefits/motivations (for branchless sequences) are threefold:
- a shorter sequence (code-size comparable to the
short-forward-branch w/ branch-hammock idiom)
- no temporary register needed
- suitable for fusion with consuming instructions

With the set + neg + and sequence as a DVIT alternative (and a clear
indication from the stakeholders in the crypto group that
cryptographic code would not benefit from having czero available as
DVIT), it appears sensible to allow maximum freedom for implementors
of czero.

Thanks,
Philipp.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/616327b2-1a12-472e-88fe-af6067c95aaan%40groups.riscv.org.

[Bruce Hoult]

> "[...] the RVWMO memory model uses syntactic rather than semantic
>  dependencies.  [...] this definition depends on the identities of
>  the registers being accessed by different instructions, not the
>  actual contents of those registers."

These are register-to-register instructions, so memory-ordering semantics between HARTs are, at best, irrelevant.

I will note that we considered such instructions in the B extension effort, but they were ultimately rejected as not offering sufficient savings relative to SLT/SLTU/SEQZ/SNEZ/SLTZ/SGTZ; NEG; AND; ANDN; OR sequences.  (Which would have been an instruction shorter if S*** had produced 0,-1 results in the first place, which would require a NEG to reify a value for C semantics only very rarely if the value was stored rather than branched on etc. But it's far too late for that now ...)

It might be useful if the document showed best sequences to emulate ARMv8's "c ? a : b+1", "c ? a : ~b", and "c ? a : -b" instructions. Including any shortcuts when a and b are the same register, as they often are.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/ZEKfuCn3Z6wvlCAe%40andrea.

[Andrea Parri]

> These are register-to-register instructions, so memory-ordering semantics
> between HARTs are, at best, irrelevant.

As long as they are not composed with memory-accessing instructions I
could agree (even though I would have used different terms probably);
otherwise, they can contribute to form preserved program order (again,
according to the present extension, "when the condition is false").

Andrea