https://libre-soc.org/openpower/sv/setvl/ specifies the behavior only in pseudocode. It would be desirable if it the textual description stated that: - MAXVL gets set to the requested value, always, as in, the immediate represents all 64 possibilities, from 1 to 64, and the hardware *must* support all of them, it can't actually set MAXVL to a value other than the requested one - VL gets set to MIN(reqVL, reqMAXVL), and never less than that. I'd got the idea from simple-v specs and from the examples on the page above that it could be less, and this was making it harder to model the svp64 insns in the compiler The first example is clearly copied from simple-v, since a0 and a3 are not ppc register names. I suppose NNNNN in 2. Format is the extended opcode, so far unspecified. It might be good to state this as well.
yep good catch, crossreferenced to 568 on the wiki page, marked as TODO.
(In reply to Alexandre Oliva from comment #0) > https://libre-soc.org/openpower/sv/setvl/ specifies the behavior only in > pseudocode. > > It would be desirable if it the textual description stated that: > > - MAXVL gets set to the requested value, always, as in, the immediate > represents all 64 possibilities, from 1 to 64, and the hardware *must* > support all of them, it can't actually set MAXVL to a value other than the > requested one yep, good wording. i haven't had time yet to locate the wording in the older spec and drag it over. it's clearly stated in the older spec, that MVL is the number of allocated registers from the scalar regfile, where in RVV MVL is hardcoded in silicon as the maximum number of physical vector lanes. > - VL gets set to MIN(reqVL, reqMAXVL), and never less than that. I'd got > the idea from simple-v specs and from the examples on the page above that it > could be less, no absolutely not. this again is repeated again and again and again in the older spec, because this is how RVV works. RVV allows it to be a "request". even the phrasing MIN(reqVL, reqMAXVL) implies a request, with some arbirary internal algorithm. it has NEVER been the case in SV tjat some arbitrary value is returned. if an arbitrary was returned, and a single instruction pair was issued: setvli r0, vl=8,mvl=8 sv.ld r5.v, 0(r20) how would you know how many actual LDs were carried out? in RVV you have ****-all idea unless you examine VL *after* the setvli, and rven if you did it's pretty useless information, you *have* to use a loop pattern just to guarantee all 8 values will be copied. why? because RVV can go, arbitrarily, "oh, you asked for 8? mmm no can't be bothered, have one instead". in SV if you ask for VL=8 (and MVL is >= 8) you damn well get VL=8. this means that yes, when you see the above pair of instructions, it is a GUARANTEED FACT that QTY 8 LD operations WILL take place, loading into r5 thru r(5+7) > and this was making it harder to model the svp64 insns in the > compiler > > > The first example is clearly copied from simple-v, since a0 and a3 are not > ppc register names. yep. time. > I suppose NNNNN in 2. Format is the extended opcode, so far unspecified. It > might be good to state this as well. again, time. and: we require an allocation from the OpenPOWER Foundation.
updated, added a rationale section