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

Hi, I agree that computing those indexes is not always trivial Some ideas you can consider (not claiming these are the most efficient ways) reverse is not too complex:

Dear Craig and Roger, ​ ​Thanks a lot for providing me goodsolution. I have tried them, they are all good solutions of upsample application. ​ ​ But, when it comes to other

Andrew Waterman called Thursday and we discussed many issues including challenges with Issues in Github. We determined that both were unaware of some relevant aspects [neither of us

Hi Linjie, I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you (logical) shift right 1 bit (vsrl.vi) would generate an index like the one

Hi, all I encountered a difficulty of applying "vrgather" instruction recently. The details are shown blow: The date from source should be duplicated as pair in a upsample application.

I've just tagged the first release candidate for v1.0 of the vector spec in github. PDF attached below. I've included the TG agreed updates and handled almost all of the outstanding issues for v1.0.

This is an excellent point, but there are only 8 SSE/AVX/AVX2 registers in 32 bit mode and 16 in 64 bit. Therefore a 32 bit RISC-V could use 32 bit VLEN and LMUL=4 to directly translate SSE code

If there was no cost, then supporting VLEN=64 on general apps processor profile would be a good thing to do. But not allowing standard software to assume VLEN>=128 imposes a non-trivial impact

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

"...if written correctly" is precisely the point. If VLEN is specified as >=128, code that targets 128-bits explicitly by setting VL to an appropriate constant for a large swath *is* correct. This

If the minimum VLEN is at least 128-bits, one can translate NEON/SSE intrinsics directly without having to have every vector instruction dominated by a loop over the vector length. -Z-

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

Software should still work with VLEN>=64 if written correctly, as it should be VLEN agnostic. Maybe it should be a recommendation that VLEN>=128, with a minimum of 64 for app processors? Lower

This is the requirement for app processors, which are not generally small cores. Most competing SIMD extensions are at least 128b per vector register. Lower performance on codes that work well on

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

see github issue #550 Krste

This is a good question. So if the RVM22 profile requires VLEN=32, ELEN=64, LMUL=8 then the vector registers will have the same amount of state as ARM MVE. Tariq

Hi, Krste: The RISC-V V TG have the plan to support a lowcost vector extension in RVMxx profile? Best Regards Shaofei 2021.6.3 -----邮件原件----- 发件人: krste@...

Hi Tony, All of the vector permutation instructions can be simulated using the memory system. For example, vslide can be simulated by storing the vector register and loading it at an offset; vrgather