1. Messages
  2. Proposing more portable vector cod

Re: Proposing more portable vector cod

David Horner
 

Never say never.
Appears to be the mantra for V extension. 


On Tue, Sep 29, 2020, 15:06 Nick Knight, <nick.knight@...> wrote:
Hi Joseph,

Thanks for the clarification.

The wording in the spec is admittedly vague: "LMUL can have integer values 1,2,4,8.", etc. My understanding of the intent is that all implementations must support the full range of LMUL values.

Yes, the intent is that the V specification mandates LMUL of 8, 4 and 1.
Even for minimal systems of VLEN=128; not only for interoperability, but because it provides a substantial functional benefit.

Future extension to larger LMUL comencerate with expansion of register set to more than 32 will likely continue to trap if supported LMUL exceeded, however, there is an opportunity then to press for auto vl sizing.

Auto vl sizing was previously discussed for all ops, not just first fault loads, nor just for widening. It is not currently on the agenda for v1.0 release.

However, it is expected that components of the V extension would be separately implementable,  verifiable and certifiable.
A reduction of LMUL could be allowed in that context.
Even an expansion of EMUL to 2*max LMUL is still on the table for post v1.0.
Joseph, thank you so much for your insightful input.


I'll defer to others to confirm or deny this.
And thanks to you Nick for replying (before I did).

Best,
Nick

...

I agree that we could make widening instructions more flexible by having them decrease VL (and LMUL) so that EMUL becomes valid. The fault-first loads adjust VL automatically, so this is not without some precedent. However, In my opinion, it's too much of a burden to do this manually (using vsetvli), and I don't see any portability issues with that.

 

_._,_._,_
Join {tech-vector-ext@lists.riscv.org to automatically receive all group messages.