Bug 568 - missing setvl/setvli behavior textual description of behavior
Summary: missing setvl/setvli behavior textual description of behavior
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Specification (show other bugs)
Version: unspecified
Hardware: PC Other
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 213
  Show dependency treegraph
 
Reported: 2021-01-06 19:57 GMT by Alexandre Oliva
Modified: 2021-01-09 18:03 GMT (History)
1 user (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Oliva 2021-01-06 19:57:34 GMT
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.
Comment 1 Luke Kenneth Casson Leighton 2021-01-07 00:11:43 GMT
yep good catch, crossreferenced to 568 on the wiki page, marked as TODO.
Comment 2 Luke Kenneth Casson Leighton 2021-01-07 04:54:33 GMT
(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.
Comment 3 Luke Kenneth Casson Leighton 2021-01-09 18:03:20 GMT
updated, added a rationale section