On Mon, 13 Dec 2021 12:09:54 -0800, "Ken Dockser" <kad@...> said:

| Reviving this old thread with a question and a suggestion:
| Question: What is the use case for supporting non-idempotent memory in a RISC-V Vector implementation as a part of a general-purpose
| rich-OS application processor? While I can certainly envision embedded applications that use non-idempotent memory, it seems unlikely
| that non-idempotent memory would be used when running arbitrary application code.

To reduce overhead, some embedded Linux systems allow user-mode code
to access devices directly, e.g., for dpdk networking. If anything,
there is a trend to support more user-level access to
devices/accelerators to reduce overhead, and to provide more isolation
between tasks (as opposed to shared device driver in kernel). Such
devices might have non-idempotent memory regions.

| Suggestion: The current Vector specification's comments about supporting non-idempotent memory can easily mislead one into thinking
| that such support is required in all compliant implementations. We need an explicit clarification in the specification along the
| lines of "Vector extension support for handling non-idempotent memory accesses is not required in implementations that prohibit or
| otherwise prevent (e.g., by trapping) such accesses." While my suggested sentence would likely benefit from some wordsmithing, I
| think that what I am trying to convey is essential in defining what is architecturally required.

We could add some non-normative text as a note to implementers, but
this allowance just follows from the general RISC-V concept that
certain memory address ranges only support certain operations (PMAs).

Calling this out as a special case in the spec could then require
repeating the statement all throughout all memory instructions for
consistency, to avoid questions about why some instructions have
optional support for some memory types versus others. We try to
factor out these concepts in the spec.

Krste


| Thanks,
| Ken
|