Hi all, If I use EDIV to compute SpMV y = A * x as size r * c blocks, I might have to load size r of y and size c of x, these are shorter than VL = r * c, is there an efficient way to do this by

The email list has the archived discussion, which should include discussion of EDIV. The main reason not to include in v1.0 is that it has many details to work through, and resolving these would delay

Hi all, Thank you Nick for the reply. I saw EDIV will not be included in v1.0, any issues to be resolved? Can I have a look at the discussion page on EDIV? Thanks a lot, Dawei

On 2020-10-26 12:48 a.m., Allen Baum wrote: That is one approach. It is a consideration that has recently been mentioned wrt misa. I remember Luke Kenneth Casson Leighton

My take: This is analogous to ascii(7-bit) and EBCIDIC(8-bit) both competing in the 8 bit byte addressable character space. Initial solutions were fragmentation, then code pages

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