I recommend flipping the polarity of LMUL[2] to ease the transition for existing assemblers. I understand the aesthetic underpinning of this encoding (especially as it might pertain to expanded LMUL

Hi Krste, I agree this is the basic solution. And very likely all we should include. Bill

I've been wading through the fractional LMUL discussion on github but believe the simple basic solution below meets the immediate needs, without blocking possible reuse of unused register fields

On 3/24/20 6:32 AM, Hanna Kruppe wrote: Agreed. Bill

Note that ELEN > SLEN has long been allowed in the spec (although it's expected that such implementations would be rare and unusual). But yes, if ELEN=64 then the natural constraint we independently

I agree, this is a useful and acceptable constraint. I proposed it in a different but equivalent formulation (SEW <= ELEN / n when LMUL = 1/n) in response to a previous fractional LMUL proposal by

... I assume that: ELEN=64b here. It can't be smaller because SEW=64b is listed. It can't be larger because SLEN=64b LMUL=1/8, SEW=32b is illegal LMUL=1/4, SEW=64b is illegal LMUL=1/8,

Date: 2020/3/20 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~20 Current issues on github: https://github.com/riscv/riscv-v-spec Issues discussed: #367, #393 The following

Intriguing. I especially appreciate the effort to identify fundamental aspects of fractional LMUL. On 2020-03-21 3:46 p.m., Bill Huffman wrote: As you mention

Maybe this has been stated already, and I just haven't seen it, but it seems like there's a constraint with fractional LMUL that wasn't there before. The compiler must ensure that: LMUL >=

I neglected to send an earlier reminder, but the vector TG meeting will be happening today per member calendar details, Krste

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

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

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

my response below is now off-topic, and covers the more flexible reductions wanted by Nagendra. i discourage any further followups here (instead, please search for another recent series of posts

Open to feedback here.. But my thought was that I will not need vslide1up if I am able to control the reduction destination. A loop around the instructions: vredsum vd[rs1], vs1[rs1], vs2[*] rs1 = rs1

to me it seems like reading the dest element index from a scalar reg sounds like a significant microarchitectural overhead. can you describe why this is needed? I would assume that use cases for this

How about if the destination element number came from a scalar register? So we will need only 5 bits to specify the x register. This may even work better than hard coding the destination inside the

regarding vector reduction destination: the V spec seems to allow for really large vector machines with thousands of vector elements. I'm not sure what the right bit width for the field with the

It appears I can not edit the wiki. But I can clarify one item. Regarding "Indexed memory accesses that implicitly scale the index by SEW/8": Explanation: In scientific sparse matrix codes (and