Max VLEN?

[aswaterman]

A note next to the vmfirst instruction says, "vector lengths will never exceed 2^31 on any implementation." Is that the only upper bound we've imposed on VLEN?

[kasanovic]

Yes. We'd need some argument for why a smaller upper bound is desirable/useful.

[kasanovic]

Constraint should be 2^(XLEN-1).

[jan-wassenberg]

@kasanovic A constraint could be useful for software to statically allocate enough space for storing a vector, as opposed to dynamic allocation of vlenb bytes. Does that make sense?

[aswaterman]

@jan-wassenberg the range of platforms RVV must support is pretty broad (current implementations have VLEN as small as 32 and as large as 4096, AFAIK), so static allocation would probably be too wasteful in practice.

Platforms can always impose their own constraints, and embedded runtimes can check vlenb at boot time and abort if appropriate.

[jan-wassenberg]

@aswaterman Thanks, interesting. Do you recall which implementation does 4096? SiFive seems to have VLEN=512. Its VLMAX=4096 with LMUL=8, but for preallocation we're interested in VLEN, right?
I agree static allocation is wasteful but can imagine some cases where it's reasonable/useful. Would be nice if a (possibly platform-specific) upper bound were known, even if it's 4096.

[hanna-kruppe]

In #367, there's even mention of an implementation with VLEN=16384, and yes that's actually VLEN (i.e., LMUL=1). This may sound excessive to you, but it's not unprecedented in HPC accelerators: NEC's SX-Aurora products have vector registers of the same size (and they have 64 architectural registers instead of 32!).

If you're fine with platform specific assumptions, you can of course reserve less space. But this does not necessarily have to be part of the standard, and depending on context it could be much smaller than 4096.

[jan-wassenberg]

@hanna-kruppe Thank you for making me aware of that. I understand that a limit <= 4K is unlikely to be included in the spec.