This is different from "fixed-width SIMD" which has a hard-coded vector length. To make things more challenging for the programmer/compiler, I believe most x86 SIMD versions also don't provide a "mask" register, so you're stuck with using all vector elements (AVX512 added masks).
Each has its advantages and disadvantages (esp. on the design complexity vs programmer/compiler interface complexity).
RVV also provides a mechanism to reconfigure the register file, ganging logical registers together to get longer effective vector lengths.
Who is going to write all the documentation and snippets for them? RISC-V docs seem to be mostly pdf based which isn't great.
If this is not the case then our programming model may end up being the same as it is on X86 since it's a easy subset of the functionality.
So sorry I was a bit confused because Cray/RISC-V is explicitly designed to be easy to use from high-level languages in a way that x86's SSE et al were not. So I thought maybe you had mixed up the two in your question or something. But I guess you just haven't had the pleasure of working with a Cray before!
The thing with the Intel model is that although the programming model in the abstract is probably worse (although I'm curious if it allows a wider processor), it is trivial to use conceptually if you understand roughly which instructions you want i.e. it's just a blob as far as the compiler is concerned.
The compiler I work on supports Intel SIMD, I'm not sure it could be easily made to get the most out of a vector programming model without a lot of rewrites. It could, however, basically emulate the fixed width things in terms of a vector ISA if needs be.
http://www.audentia-gestion.fr/CRAY/PDF/Cray_C_and_C___Refer...
You literally just write regular old C code doing a tight inner-loop computation, and use pragmas to tell the compiler what it needs to safely parallelize.
Of course these days you can do the same thing in any vectorizing compiler. But the point is that a modern vectorizing compiler has to do some pretty impressive transformations to generate SIMD code which looks nothing like the original, whereas the Cray code pretty much compiles to the same thing when vectorized.
In very tight situations it's common to write SIMD intrinsics directly rather than rely on the compilers ability to make the transformations itself. Intel's SIMD maybe be ugly but it is also very topologically easy to navigate, if that makes sense.
I'm going to write some arm SVE code and compare, at some point.
This is all I remember, there is probably more.
Machines with any size vector registers handle code specifying vector length of 1 (or 0!) no problem.
If you really want to make a machine with vector registers that hold only one element then that will work too, except for a handful of instructions that simply don't make sense in that case (unless you use the LMUL feature): vector permute register, slide up, slide down.
CPUs intended to run standard operating systems with shrink-wrapped software are constrained in the RVA22 profile to provide vector registers of at least 128 bits and no more than 65536 bits. But if you're doing some custom embedded custom CPU then you can make the vector registers the same size as the integer registers (32 or 64 bits). Note that if you do that, you can still usefully do vector operations on chars and shorts, and you can also set LMUL=8 to give you effectively four vector registers of 256 or 512 bits each (which might or migth not be processed serially).