Re: Vector Memory Ordering
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.
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.