Public review for standard extensions Zicbom, Zicbom, Zicboz

[Stephano Cetola]

We are delighted to announce the start of the public review period for
the following proposed standard extensions to the RISC-V ISA:
Zicbom - Cache Block Management Operations
Zicbop - Cache Block Prefetch Operations
Zicboz - Cache Block Zero Operations

These extensions are part of the Privileged Specification.

The review period begins today, Thursday Sept 16, and ends on Sunday
Oct 31 (inclusive).

These extensions are described in the PDF spec available at:
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v0.6pdf

which was generated from the source available in the following GitHub repo:
https://github.com/riscv/riscv-CMOs/tree/master/cmobase

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 CMO GitHub repo: https://github.com/riscv/riscv-CMOs. 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 CMO Task Group. 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 Privileged 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.

Kind Regards,
Stephano
--
Stephano Cetola
Director of Technical Programs
RISC-V International

[K. York]

2.5.2 - the remark seems to have some backwards reasoning. Store permission implying load permission is not a reason to exclude checking for store permission from operations that require load permissions; it is a reason to exclude checking load permission from operations that require store permissions (cache block zero does not need to check for read).

2.5.2 - an actor that can only read a particular memory page being able to discard writes (Invalidate cache management operation) from another (potentially higher privileged) actor sounds problematic initially. The remark should direct readers to Chapter 3 where this concern is addressed.

5.1 - If the synopsis is not supposed to be terminated by punctuation (if it is there's a typographical error), then this should be significantly shorter, feel like it's "not supposed" to be a complete sentence.

Perhaps: "Perform a [clean|flush|invalidate] operation on a cache block"

5.1 - The instruction description should mention that rs1 selects the cache block, interpreted as a virtual address of the current privilege level.

5.3 - Style: replace "however" with "instead" and delete the commas.

5.4 - Synopsis "Store zeroes to a full cache block", mention rs1 in description.

5.5 - Mention calculation of base+offset, note that offset[4:0] is both always zero and is part of the instruction encoding by setting rd to 0.

Thanks.

--
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/CAEY315g_3h7hQuxGhFtkhTy-G-Fmrb6skU%3D58-0MJB0z9z6B%3DQ%40mail.gmail.com.

[Roger Espasa]

2.6 I would like a clarification added to 2.6 on whether a cache-management operation or cache-block zero instruction can cause the cancellation of an LR monitor reservation *in the same hart* or not.  The text mentions "on another hart", but it's not clear what happens on the same hart. It would also be good to fully specify how the PREFETCH instructions affect an LR monitor: does an implementation have full freedom to cancel the LR monitor in the hart issuing the prefetch? If so (or otherwise) it would be good to state it in the spec.

Thanks

roger.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CABeNrKXhcee_gnHQm0USooNdWjDpfZeu5vt%2Bzvg_VB%3D%3D160pFQ%40mail.gmail.com.

[Andrew Waterman]

Hey Roger,

On Fri, Sep 17, 2021 at 12:38 AM Roger Espasa <roger....@semidynamics.com> wrote:

2.6 I would like a clarification added to 2.6 on whether a cache-management operation or cache-block zero instruction can cause the cancellation of an LR monitor reservation *in the same hart* or not.  The text mentions "on another hart", but it's not clear what happens on the same hart. It would also be good to fully specify how the PREFETCH instructions affect an LR monitor: does an implementation have full freedom to cancel the LR monitor in the hart issuing the prefetch? If so (or otherwise) it would be good to state it in the spec.

I can comment authoritatively on the latter question.  PREFETCH instructions are merely HINTs, which means they have no semantics, and they have no affect on LR/SC eventuality, beyond what the old specs say.

Informally, it's fine if hart A's prefetch cancels hart B's reservation, as long as hart B is eventually able to complete its LR/SC loop (subject to existing constraints).  Note this is true even if A == B.

The lack of new normative text is deliberate, because the old normative text in the LR/SC section suffices.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAD%3DxdLgnC7bbDAZT2QHEkzuR-toyXLCYafoBz0mfUJB2%3DwBrGg%40mail.gmail.com.

[David Kruckemyer]

Hi all,

Thanks to everyone for the feedback so far. Just making a minor correction to the list of recipients for now so I can receive the messages directly. 

Cheers,

David

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0B5VcRkZaBT0RK0sXpBrwSN9ZX85MX5-DdF8Rh-itC7Ew%40mail.gmail.com.

[Roger Espasa]

Thanks Andrew. 

I would still err on the side of verbosity and add your explanation to the spec. It will help implementers to "get it right on first read".

roger.

[Stephano Cetola]

On Thu, Sep 16, 2021 at 5:01 PM Stephano Cetola <step...@riscv.org> wrote:
>

> These extensions are described in the PDF spec available at:
> https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v0.6pdf

Apologies, missed some punctuation:
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v0.6.pdf

Cheers,
Stephano

[Jeff Scott]

Pdf link below does not work. Can you send a working one?

Jeff

-----Original Message-----
From: Stephano Cetola <step...@riscv.org>
Sent: Thursday, September 16, 2021 7:02 PM
To: isa...@groups.riscv.org
Cc: dkruc...@ventanamicro.com; ziyi...@c-sky.com
Subject: [EXT] [isa-dev] Public review for standard extensions Zicbom, Zicbom, Zicboz

Caution: EXT Email

We are delighted to announce the start of the public review period for the following proposed standard extensions to the RISC-V ISA:
Zicbom - Cache Block Management Operations Zicbop - Cache Block Prefetch Operations Zicboz - Cache Block Zero Operations

These extensions are part of the Privileged Specification.

The review period begins today, Thursday Sept 16, and ends on Sunday Oct 31 (inclusive).

These extensions are described in the PDF spec available at:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-CMOs%2Fblob%2Fmaster%2Fspecifications%2Fcmobase-v0.6pdf&amp;data=04%7C01%7Cjeff.scott%40nxp.com%7Cbe7885d687794b1d8fc308d9796e5a60%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637674337131763886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=me9%2BdRzFl1jAySeTFVgjjC7b3lVVRw3aV%2Bz2HfmH4SA%3D&amp;reserved=0

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-CMOs%2Ftree%2Fmaster%2Fcmobase&amp;data=04%7C01%7Cjeff.scott%40nxp.com%7Cbe7885d687794b1d8fc308d9796e5a60%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637674337131763886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9HYejWHoCqQ9mqGvBxq1wCIVyw81n6PqqUJIR9k0hwE%3D&amp;reserved=0

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 CMO GitHub repo: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-CMOs&amp;data=04%7C01%7Cjeff.scott%40nxp.com%7Cbe7885d687794b1d8fc308d9796e5a60%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637674337131763886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4fTzyV%2F5y6pqPU4ASb70C%2FMWpjwOKfkCA%2B1XEJZKOnI%3D&amp;reserved=0. 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 CMO Task Group. 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 Privileged 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.

Kind Regards,
Stephano
--
Stephano Cetola
Director of Technical Programs
RISC-V International

--
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fgroups.riscv.org%2Fd%2Fmsgid%2Fisa-dev%2FCAEY315g_3h7hQuxGhFtkhTy-G-Fmrb6skU%253D58-0MJB0z9z6B%253DQ%2540mail.gmail.com&amp;data=04%7C01%7Cjeff.scott%40nxp.com%7Cbe7885d687794b1d8fc308d9796e5a60%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637674337131763886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=FqUREMDAmWsUT19Fioaa3HOygcC%2BcJzWGHWucBwVBKc%3D&amp;reserved=0.