> [`vsetvli`] 6x src/dest registers?! So CISC then? No, that's desired and resulting actual vector length (2 registers), plus four fields of `vtype` (totalling

> [`vsetvli`] 6x src/dest registers?! So CISC then? No, that's desired and resulting actual vector length (2 registers), plus four fields of `vtype` (totalling 8 bits) which are present as a literal in the instruction for `vsetvli` or in `rs2` for `vsetvl`, stored into the `vtype` CSR, which is renamed / attached as extra bits to each decoded vector instruction as if they'd been bits in the opcode in the first place (which they will be in future 64-bit instruction encoding in RVV 2.0 (or so). This and his other RVV comments make me think he's seen a little RVV code but hasn't actually read the manual. > I see no viable pathway to build RVV at any level of out-of-order performance [...] completely overlook what it would take to build the machine The RVV working group had micro-architects who have created famous vector processors in the past, most famously (for me) Steve Wallach, 2008 recipient of the Seymour Cray Computer Science and Engineering Award for his "contribution to high-performance computing through the design of innovative vector and parallel computing systems, notably the Convex mini-supercomputer series". Also Roger Espasa was very influential. He presented recently on what it takes to build a high performance OoO RVV implementation. Some people interpret his description of the challenges as being a criticism. It is not -- Roger was there when it was designed, knew what the challenges would be, knew how they would be solved, and considered it to be worthwhile to make the hardware designers work a little to make life easier for programmers. [1] https://en.wikipedia.org/wiki/Steve_Wallach https://en.wikipedia.org/wiki/Steve_Wallach