|
|
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
|
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
|
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 -
|
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
|
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
|
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
|
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
|
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
|
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
|
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@...>;
|
-----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
|
| 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
|
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
|
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@...;
|
-----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
|
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),
|
|| 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
|
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
|
| 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
·
|
