The question I have is whether having this in scalar only would be sufficient? If porting an application were to need exception traps, it seems plausible to disable compiler vectorization. The MIPS

Yes, this would be the obvious path to take. Some use cases, including maybe this one, might prefer FP traps to be horizontal into user mode. There is the old MIPS FPU pipeline trick of conservative

Completely agree. Was very happy RISC-V did not include FPU exceptions. Jeff From: tech-vector-ext@... <tech-vector-ext@...>On Behalf Of Andrew Waterman via lists.riscv.org Sent: Friday,

Defining a standard extension that provides precise traps on FP exceptions seems like a reasonable thing to do, if only to facilitate the use case you mention in a standard way. The strategy would

While I understand that it had been decided long ago (relatively speaking) that RISC-V would not support trapping on floating-point exceptions, I am wondering if we need to revisit this. I have heard

For the current V extension, it's correct to treat both vcsr and vstart as 32-bit registers. I agree the spec should clearly indicate whether or not these registers will always be 32 bits (like

Hi,all Debuggers can use abstract commands to access CSRs. When using abstract commands, debuggers need to specify the bit width of CSRs. The bit widths of vcsr and vstart are not clearly defined in

| 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 |

Upstream maniline binutils had rvv 1.0 support added recently. This isn't in any release yet, so you have to use the top of the development tree. Upstream LLVM has had rvv support for a while,

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

I am working on some experiment and I need to simulate RVV r1.0. Is spike my best bet for this? All I want to start with is writing bare metal assembly, and copy some memory buffers between the sim

Simple implementations could simply execute it sequentially. Or have the trap handler execute the loads sequentially if any of them fault. We don't care how slowly malicious code runs. It plays just

On 2021-11-17 10:33 p.m., Bill Huffman wrote: First there is currently no ff gather. But if there were, the vl would need to be truncated to the first in sequence that

So if I set up indexes on a ff gather so that I ensure the first one is legal while the rest access pages I want to probe, how does the higher privilege software know I learned about all those

The trap if first address bad is stipulated behaviour. The other are not specified in the vector extension , but 1. the counter is part of the generalized performance spec. 2. Always trap but allow

Are the mechanisms you mentioned hypothetical future ISA extensions, or something included in the current vector extension? In particular, I don't see anything about M-mode and/or HS-mode requesting a

that should have been "The HS is in control, it can "leak" or not as it sees fit" obviously. On 2021-11-17 9:16 p.m., David Horner via lists.riscv.org wrote:

On 2021-11-17 8:45 p.m., Andrew Waterman wrote: The VS having this awareness can be very beneficial. It allows the OS to better manage its resources. It can switch to

Yeah, agreed that detecting paged-out pages is a similar information leak. (Though I think COW is not relevant here, since we're only talking about load instructions.)

The physical address space that the hypervisor tells the guest about may not match the one installed in hgatp. For instance, some pages of the guest's memory might be marked copy-on-write or swapped