Should lmul[2:0] be contiguous in vtype?

[kasanovic]

For backwards compatibility with earlier tool chains and implementations, reverted change to make expanded lmul contiguous (#432).
Should we reformat to make lmul contiguous before base 1.0?

[jnk0le]

Is that "backwards compatibility with pre-freeze drafts" going to remain with us forever like in some other specs?

[kasanovic]

This was a local revert to reduce churn in implementations. This issue is exactly about whether to make contiguous in final spec. There will undoubtedly be some other incompatible changes in spec before 1.0 is frozen, this is about reducing the number of intermediate updates implementation teams have to do.

[nick-knight]

I would vote yes on aesthetic grounds. My question is whether you intend V-ext to be extensible to allow additional LMUL or SEW values, and, if so, where these bits would go.

[kasanovic]

The immediate in vsetvli only allows 11 bits (12th is taken to differentiate vsetvli from vsetvl), so it's unlikely any of these fields (SEW/LMUL) will grow within that 11 bit limit (after EDIV, there's only two bits left). We can treat vtype as an 11-bit window into a much larger vtype CSR, which could have larger contiguous fields if we add more SEW, LMUL, etc variants. So common cases just use a single vsetvli whereas complex types need a LUI + vsetvl for example. ILEN=64 encoding would bypass vtype.

[aswaterman]

I vote no, unless there is some other compelling reason to make another backwards incompatible change to this register.

I agree on the aesthetics, but it’s not enough for me.

[jnk0le]

Apart from asthetics, software emulators have to concatenate those scattered fields.

[aswaterman]

I think we already crossed the bridge of not optimizing for software emulators when we chose the branch/jump and RVC immediate encodings...

[kasanovic]

Group decided to regroup bits for v1.0 release.

[David-Horner]

UPDATE: I reversed my stance (because I erred).
Consistent with group decision the table would be:

Bits	Name	Description
XLEN-1	vill	Illegal value if set
XLEN-2:10		Reserved (write 0)
9:8	vediv[1:0]	Used by EDIV extension
7	vma	Mask agnostic
6	vta	Tail agnostic
5:3	vsew[2:0]	Standard element width (SEW) setting
2:0	Vlmul[2:0]	Vector register group multiplier (LMUL) setting

ORIGINAL POST:
I anticipate further variations of lmul that would require expanding the field size.
SEW also may need expansion to support novel types.
I therefore propose that in addition to consolidating the components of lmul, that we add one bit space between sew and lmul.
This would allow either sew or lmul to grow as future needs are determined.
It still allows room for ediv expansion.
Obviously, the bit could alternatively be a flag bit for other expansion as noted in #460

Bits	Name	Description
XLEN-1	vill	Illegal value if set
XLEN-2:11		Reserved (write 0)
10:9	vediv[1:0]	Used by EDIV extension
8	vma	Mask agnostic
7	vta	Tail agnostic
6:4	vsew[2:0]	Standard element width (SEW) setting
3		Reserved (write 0)
2:0	Vlmul[2:0]	Vector register group multiplier (LMUL) setting

[aswaterman]

I have to say 👎 to this. It’s more disruptive now than it was during the 0.9 transition, so the justification for keeping it constant for 0.9 applies more to 1.0, not less.

[David-Horner]

I agree with @aswaterman that reserving the bit between sew and vlmul is inappropriate.
Not because it displaces vta, vma and ediv, but because I erred in counting the available bits.
bit 11 is not available to extend ediv in vsetvli
As a result special consideration for sew and vlmul expansion over ediv is dubious at best.
Indeed, with only one bit left we have approached the threshold at which that 1 bit should be reserved for signaling expansion.