We will be meeting again this morning. I hope to focus on closing on features for upcoming 0.9 release. Krste

Yes - agreed. I believe it is going to be considered for support in the 64 bit encoding. Best regards Nagendra

On #2, it would require finding a 2 bit field in the vector load format to encode "no-scaling/2/4/8". Not trivial within the 32b format. On Wed, Mar 11, 2020 at 1:30 AM Nagendra Gulur

On 2020-03-24 11:40 p.m., Krste Asanovic wrote: I attempt to summarize the needs here: 1) to reduce the register pressure that successive levels of LMUL invoke (halving

Not really challenge :-) But it's the only option if you can't / don't want to add a "vstart" equivalent (because you don't want to save/restore it...) @Nagendra: note that the spec does require the

Intel's Larrabee machines had something like this - where indexed loads cleared down a mask of completed accesses. I think it's a very bad design pattern for something as common place as an indexed

I suggest to treat fractional LMUL as a negative power of 2: 1/2 = 2^-1, 1/4 = 2^-2 Already LMUL == 2^vtype.vlmul , so no changes needed for all values of vtype.vlmul that are already in the

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