i have not been following this thread in lots of detail could someone please explain why we need to differentiate between ordered and unordered load/stores. in the 6 or vector systems i have been

Guy Lemieux commented: Maybe what's below could be improved by saying that if the base address (in src1) was non-idempotent or an "ordered channel," the entire instruction would run in order. If

I think from this morning, we are considering: Ordered scatters are done truly in order Strided stores that overlap (including segmented ones) will trap as illegal All other vector loads and stores do

Though I don’t know if we’re affected by calendar changes, Krste

Andrew, Nick, Thank you for the quick responses. Nick, the text updates look like they directly reflect the intent. -Cohen

Thanks Krste, that makes sense but the logic is not that straight forward, people usually needs "decompress" when they are using "compress", maybe we can add some comment on this at the "vcompress"

If the decompress is the inverse of compress, then there will be a packed vector holding the non-zero elements and a bit mask indicating which elements should receive the elements after unpacking

Hi all, For common AI workloads such as DNNs, data communications between network layers introduce huge pressure on capacity and bandwidth of the memory hierarchy. For instance, dynamic large

Correct, Krste

Hi all, I understand the EEW, as explicitly encoded in the load/store instructions applies to the vector of indices for the indexed loads and stores. For instance we can load a vector "SEW=8,LMUL=1"

Hi Cohen, Thanks for your careful reading. Hopefully this edit clarifies some of the ambiguity: https://github.com/riscv/riscv-v-spec/pull/565 Best, Nick Knight

The non-normative text you quoted should be edited to delete the words “it is signed”. The immediate is sign-extended, but then is treated as an unsigned value. So the operation doesn’t differ

From chapter 11, section 1 (#3): The 5-bit immediate is unsigned when either providing a register index in vrgather or a count for shift, clip, or slide. In all other cases it is signed and sign

Sorry for late notice, but I have to cancel the vector tech meeting today, Krste

Thank you for the clarification. Excellent.

The user can call functions anything they want. The example might be better if this was clear by calling it foo() or demo_vector_add() or something. The variable "a" in an "int *" pointer. When you

Thank you very much for this advancement. I have two concerns, in the body is a response. . On 2020-08-21 9:34 a.m., Kito Cheng wrote: Shouldn't this be

Just a reminder that we will differentiate between branding (i.e. what we trademark and what members can advertise) and internal use (like uname in linux vs. splash screen, etc.). the proposed policy

thanks - I am OK with whichever you choose.-- ==================================================================== The information contained in this electronic mail message and any attachments

Anybody is free to use any subset of supported instructions and element widths/types. The Z names can be extended down to individual instructions/width if necessary. However, we have to guide the