Special lmul code in vsetvl{i} to derive LML from existing SEW/LMUL and provided sew code. As mentioned in the TG we suggested widen LMUL to 3 bits with 7 (explicit) states. I suggest we name them l1,

I left the encoding unspecified in the proposal. That was intentional as I saw various tradeoffs. However, I now recommend the codes be in order of increasing VLMAX value as so: vlmul mnemonic LMUL VL

I'm sending out to the correct mailing list a copy of the revised issue #393. (link: https://github.com/riscv/riscv-v-spec/issues/393 ) This was requested at the last TG meeting. I believe it is consi

My apologies, especially to those who have sent some feedback. I had thought I had already sent this second iteration (It has been on git hub issue since Monday. A slightly less simple design to parti

I am sending out the partial description of the next itteration for the Simple Fractioanl LMUL design. It is incomplete because I only recently clarified in my own mind a means to represent the concep

This is the fourth installation of the Simple Fractioanl LMUL design. It does not yet address SLEN and a suggestion for a fractional SLEN (fracSLEN). It should however clarify the ramifications of the

Intriguing. I especially appreciate the effort to identify fundamental aspects of fractional LMUL. As you mention below this constraint is problematic when VLEN=ELEN, or a low multiple of VLEN. I appr

I attempt to summarize the needs here: 1) to reduce the register pressure that successive levels of LMUL invoke (halving register addresses each level) this arising from the need/desire 2) To replace

I agree Nick. So here is a suggestion, not completely facetiously: For load byte/half/word example when SEW = 64 An implementation can optimize the sequence strided load by 1/2/4 shift left 56/48/32 a

I agree, It's more important to gather and evaluate actual application kernels. Is there such an effort on-going? I further agree to the implicit idea that much, even most, of the processing in any gi

Previous issues I opened on fractional LMUL were exploratory, suggesting various ways to encode and enable the feature. The latest 4 issues opened on github are specific proposals based on the strawma

What of SEW scaling factor instead. 1/4,1/2,1 and 2. This allows a much expanded dynamic range and addresses most scaling concerns. It allows of 2 * SEW for vwop.wv source load, and store of all widen

I believe I believe these widths are the appropriate ones. See the explanation above. The rationale being widening (and narrowing) instructions are already SEW based, so are single SEW instructions an

As I had asked that pagan question of opcode space I thought I should try to address the problem: I opened issue https://github.com/riscv/riscv-v-spec/issues/423 Which I paste here for your convenienc

First thoughts below - as a response to #424 and - we need only consider SEW = LEW (new) and 1/2LEW (POR) When completed is it LEWd? With the corresponding lmul = lmul/2 + lmul/2 Which biases towards

For those not following on github:

Thank you very much for this. I started a pull request, but was including as an extension and still debating the best way to incorporate. Would it be possible to generate a pdf for what is now a subst

First some observations from the revised LMUL. *1 The format for a given SLEN and SEW is the same for all LMUL>=1 *2 LMUL=n is equivalent to LMUL=2 * n with vl < 1/2 vlmax at that level, for n=1,2,4.

OK. Again thanks. I will generate a few versions and compare incrementally. Will report the anomalies if they show up in your weekend efforts.

Yes it is. However, it needn't be, and allowing it to not be gives greater flexibility at minimal cost. This was a suggestion to implement #418. [Introduce vlmt (vl multiplicative threshold) / VLMT Ve