Hi all, I was wondering if the group has considered before (and rejected) the following register layout proposal. In this scheme, there is no SLEN parameter, instead the layout is solely defined by

I appreciate your agreement with my analysis, Krste. However, I wasn't drawing a conclusion. I lean toward the conclusion that we keep the "new v0.9 scheme" below and live with casts. But I

for those not on Github I posted this to #461: I gather what was missing from this were examples. I prefer to consider clstr as a dynamic parameter, that some implementations will use

Correct I don't understand the reason for this constraint. Still not got it. clstr is not a count but a size. When CLSTR is 32 this last row is 7 5 3 1 6

I think Bill is right in his analysis, but I disagree with his conclusion. The scheme Bill is describing is basically the v0.8 scheme: Eg: VLEN=256b, SLEN=128b, SEW=32b, LMUL=4 Byte

It’s looks like a better change to move the intrinsic RFC to the riscv github :) —Jojo 在 2020年5月24日 +0800 AM10:49，Kai Wang <kai.wang@...>，写道：

Indeed, the EPI team is the first one to publish their intrinsic interface and implementations. They give us lots of suggestions about the intrinsics design. The RFC could not come out without their

Thanks for your feedback. From your description, it is very similar to SiFive internal design. I totally understood why you have these arguments. There are already lots of discussions in the Github

Hi all, Firstly, thanks for the vector intrinsic specification RFC. It's a very timely proposal that meets exactly the requirements of RISC-V fans. We have learned a lot from it. As far as we know,

Hi, We (Andes) have also been working on RVV intrinsics with our lead customers for a while, and we appreciate that you published this RFC to spur discussion about vector intrinsics. After reviewing

that may be For me the definitions contained in 1,2 and 3 need to be more rigorously defined before I can agree that the constraints/behaviours  described are provably inconsistent on

No, the data types are for a vector of elements. The arguments are vectors of elements, not element data types.

I believe it is provably not possible for our vectors to have more than two of the following properties: 1. The datapath can be sliced into multiple slices to improve wiring such that

Nor was I intending on implying that you believed these casting instructions would affect the memory system. Although Krste and I believe Andrew did suggest the memory side of the register file could

Hi David, I wasn't at all trying to suggest that we could use the store/load combination instead of defining cast instructions. I was only trying to verify the required operation. You said that

By the way, this is similar to the "prefix" proposal that applies the transform to selected source and/or destinations. The cost is reduced as the "transform" is occurring while the operation is also

I would agree that "by definition" this is a sufficient condition to obtain the instructions that Krste was envisioning of instructions the also nop on SLEN=VLEN machine. That is a sufficient

It seems like the function of a cast instruction the same as storing to memory (stride-1) with one SEW and loading back the same number of bytes with another SEW. Is that a correct understanding?

We have tagged version 0.9 on github, including HTML/PDF artifacts: https://github.com/riscv/riscv-v-spec/releases/tag/0.9

Date: 2020/5/15 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~20 Current issues on github: https://github.com/riscv/riscv-v-spec Issues discussed: #