Hi, The way 18.1 and 18.2 currently read in the V spec is a bit confusing. It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor". 1) Pr

I’ve taken a stab at reducing the number of instructions in my RVV-lite proposal. The overriding goal, in my mind, is to preserve forward software compatibility so the ecosystem doesn’t need to fragme

thanks, I see the api comments now too. pretty easy to do using vslide1up/dn and vmerge g

for zip, you don’t need to use vrgather. instead, use vector widening (eg vwaddu with x0) to double the element size (ensuring the MSBs are 0) for one half of the set. apply vslide1up and widening to

that's pretty handy, actually. I'm not sure it should be a property of the V spec itself, rather it could be a requirement that software which is translated in this method could require an implementat

Krste, to be clear,The issue The RVV spec should be inclusive, rather than exclusive. Setting VLEN Sorry I wasn't clear. Of course, an implementation with VLEN=64 would likely be slower than one with

What is the advantage to RVV requiring VLEN >= 128? I think this should be changed to VLEN >= 64 because: 1) VLEN = 64 is more likely for small implementations; creating a mandatory expectation to imp

I think the concern here is lack of a clearly defined data layout pattern for such cases. eg, should the LSBs be in the odd or even register half, or should it be implementation-defined? Guy

For widening and narrowing instructions to work, the V spec depends upon changing SEW (to EEW) and LMUL (to EMUL), such that EEW/EMUL == SEW/LMUL. That is, to change the element size (widen or narrow)

Allowing VLEN<128 would allow for smaller vector register files, bit it would also result in a profile that is not forward-compatible with the V spec. This would produce another fracture the software

yeeesh glad i don’t have to stare at that code too long. i know it’s not your code ... i think it could use a abs followed by a max reduction, then do the rest as scalar ops? these macros appear to be

It depends -- exactly what do you plan to do after determining if a mask is all-0 or all-1 or other? vpopc and vfirst can both special-case these common results via precomputation, so they both take m

Hi, I’m starting a project where we want to use vector intrinsics and generate both 64b and 32b code (for RV64 and RV32). It looks line the best way to do this right now is with GCC, where we were abl

in terms of overlap with that case — that case normally selects maximally sized AVL. the implied goals there are to make best use of vector register capacity and throughput. l i’m suggesting a case wh

I agree with you. I had suggested the mapping of 00000 to an implementation-defined value (chosen by the CPU architect). For some architectures, this may be 16, for others it may be 32, or even 2. The

for vsetivli, with the uimm=00000 encoding, rather than setting vl to 32, how setting it to some other meaning? one option is to set vl=VLMAX. i have some concerns about software using this safely (eg

I think this is a bad idea for both loads and stores. If the intent is a single load or single store, then there should be another way to do it. Using vector loads/stores with stride=0 is one way to r

Thanks Tim, I think that sums it up nicely. I just wanted to put a pointer out to the original post that I made on isa-dev regarding opcode sharing / management: https://groups.google.com/a/groups.ris

I think a common embedded and FPGA scenarios will be F on the scalar side but no F on the vector side. Adding F to V is nontrivial in area, particularly for FPGAs that lack FPUs, yet an integer-only V

Alex, Keep in mind: a) I amended my proposal to reduce the code bloat identified by Nick b) the effect of the bloat is almost entirely about text segment size, not power or instruction bandwidth, beca