tech-vector-ext@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: RISC-V Vector Extension post-public review updates - fault flagging

Could someone say what these control mechanisms are? In particular, it seems like a VS-mode guest operating system could probe the entire guest physical address space using fault-on-first load without

By Jonathan Behrens <behrensj@...> · #747 ·

Re: RISC-V Vector Extension post-public review updates

SVE uses a special dedicated FFR register to hold these first-faulting load mask bits. RVV just reuses vector length register in a natural way. Krste

By Krste Asanovic · #746 ·

Re: RISC-V Vector Extension post-public review updates - fault flagging

On 2021-11-17 5:36 p.m., Krste Asanovic wrote: However, we did discuss its merit; if it would trump the encoding dificulties, see below - there are two aspects here -

By David Horner · #745 ·

Re: RISC-V Vector Extension post-public review updates

Yes, for safely vectorizing loops with indirect references and data dependent control flow. I didn’t see how the mask result did that. Having it be zero for all elements after the one that fails

By Bill Huffman · #744 ·

Re: RISC-V Vector Extension post-public review updates

The primary reason was lack of encoding space for non-unit-stride fault-on-first instructions. The security concern was being able to probe addresses to find accessible regions without free of being

By Krste Asanovic · #743 ·

Re: RISC-V Vector Extension post-public review updates

Because otherwise you can't safely vectorise loops that do indirect array accesses (e.g. a[b[i]]) with data-dependent control flow. I don't think there is any additional security implication. I could

By Bruce Hoult · #742 ·

Re: RISC-V Vector Extension post-public review updates

On 2021-11-17 4:32 p.m., Bill Huffman wrote: I am curious as well. It makes sense when the whole vector is participating and masking is the only means to limit processing, but

By David Horner · #741 ·

Re: RISC-V Vector Extension post-public review updates

By Bill Huffman · #740 ·

Re: RISC-V Vector Extension post-public review updates

Don't forget some code may want to use a mask in inverted sense for individual instructions, without explicitly creating a new mask. This was not listed in the "wish list for 64 bits" below, but it

By Bruce Hoult · #739 ·

Re: RISC-V Vector Extension post-public review updates

Not necessarily with a larger mask register specifier. For example, with 3b mask register specifier, we could expand to encode v0-v6 as mask sources with 111 meaning unmasked. Krste

By Krste Asanovic · #738 ·

Re: RISC-V Vector Extension post-public review updates

-----Original Message----- From: krste@... <krste@...> Sent: Wednesday, November 17, 2021 1:02 PM To: Bill Huffman <huffman@...> Cc: Grigorios Magklis <grigorios.magklis@...>;

By Bill Huffman · #737 ·

Re: RISC-V Vector Extension post-public review updates

| From: Grigorios Magklis <grigorios.magklis@...> | Sent: Tuesday, November 16, 2021 12:03 PM | What is the thinking for when we go to >32-bit encodings with respect to vtype | and

By Krste Asanovic · #736 ·

Re: RISC-V Vector Extension post-public review updates - 32bit opcode decision

On 2021-11-16 12:15 p.m., Bill Huffman wrote: Yes, absolutely. Many vector models historically have been co-processors with their own internal status. RVV integration is also

By David Horner · #735 ·

Re: RISC-V Vector Extension post-public review updates

By Bill Huffman · #734 ·

Re: RISC-V Vector Extension post-public review updates

What is the thinking for when we go to >32-bit encodings with respect to vtype and masks? I assume that the longer encoding could encode SEW (and LMUL?) as an override of vtype. What about masks

By Mr Grigorios Magklis · #733 ·

Re: RISC-V Vector Extension post-public review updates

-----Original Message----- From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic Sent: Tuesday, November 16, 2021 11:13 AM To: ghost <ghost@...> Cc: krste@...;

By Bill Huffman · #732 ·

Re: RISC-V Vector Extension post-public review updates

Almost all vector instructions already have to check their vector operands to make sure the register numbers are compatible with (dynamic) LMUL. This is further complicated in, e.g., the case of

By Nick Knight · #731 ·

Re: RISC-V Vector Extension post-public review updates

|| 1) Mandate all implementations raise an illegal exception in this || case. This is my preferred route, as this would be a minor errata for || existing implementations (doesn't affect software),

By Krste Asanovic · #730 ·

Re: RISC-V Vector Extension post-public review updates

I agree that #1 is the least unfortunate of the alternatives, but I want to raise a flag because I think there are larger considerations. AFAIK, the vector extensions are unique among proposed

By ghost · #729 ·

Re: RISC-V Vector Extension post-public review updates

| From an ISA definition point of view it doesn't make sense to forbid properly formed operations to benefit a | specific hardware implementation. It's an ugly hack. A common goal in ISA design is

By Krste Asanovic · #728 ·

141 - 160 of 887

Home Hashtags Subgroups Terms