Are we talking about something that is effectively bank switching the opcodes here? Something like that was proposed very early on, using a CSR (like MISA maybe - the details are lost to me) to enable

There is text in some places stating this, but it is also something that needs to get reemphasized in the base ISA manual intro. Krste

Did you keep/add text encouraging implementations to indeed raise illegal on reserved encodings ? I went through the patch (rather quickly) and did not see it. Roger

I'm working through updates to vector spec, and one part of clean up is changing text where it has mandatory raising of illegal instruction exceptions on unsupported encodings to instead state the

Reminder: No meeting next Friday October 30. Date: 2020/10/23 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~12 Current issues on github:

These are all important considerations. However, what they have in common when considering Allen's question: is that they are all tactical considerations are in the

On 2020-10-21 6:33 p.m., swallach wrote: https://github.com/riscv/riscv-v-spec/issues/587#issuecomment-711087236 To clarify, Andrew's reading of the spec has vstart>= vl

i have not totally been following this discussion. but at convex we handled this very simply if Vl = 0, no vector operation was executed, and the vector instruction was executed and sequential

- [tech-cmo] so they don't get bothered with this off-topic discussion | [DH]: I see this openness/lack of arbitrary constraint  as  precisely  the strength of RISCV. | Limiting vector

Hi Dawei, Unfortunately the V-extension does not currently feature block-matrix multiplication instructions, including the bit-masked versions that you're describing. Some of these operations are

You're incorrectly characterizing FoF below. The FoF loads are not intended for software to dynamically probe the microarch state to check for possible faults

Date: 2020/10/16 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~16 Current issues on github: https://github.com/riscv/riscv-v-spec # Definition of

If we allow regular FoF loads to return with vl=0, we must provide a forward-progress guarantee, otherwise the instructions are practically unusable. The forward-progress guarantee must not add

Hi， Perhaps instead of using bit vector to encode an entire matrix, we can encode a sub block. There is a common sparse matrix format called BCSR that blocks the non-zero values of CSR, so that we

Krste: I gather your answer is more in the context of lr/sc type forward guarantees, instructions that are designed not to trap when delivering on their primary function.    So  I agree that

Sure. You could guarantee forward progress, e.g. by allowing no more than 10 successive "first fault" with VL=0, and requiring trap on element zero on the 11th. That check could be in

Here's the strlen example from spec: .text .balign 4 .global strlen # size_t strlen(const char *str) # a0 holds *str strlen: mv a3, a0 # Save

So all the vleff use cases end up then using a vmpopc of some sort to determine the exit condition and never use the trimmed VL ? (other than, of course, to control within the while how many elements

I don't think the cases where there was no fault look any different to software than the fault cases. Either can happen anywhere and the while loop may continue. The while loop isn't ended by a

We're all in agreement that if the spec says "pick where you stop" we'd all pick to trim to VL=3. I was under the impression this was not yet closed (in light of the "stop at cache misses"