There's a large overlap here with the (rd!=x0,rs1=x0) case that

selects AVL=VLMAX.  If migration is intended, then VLMAX should be

same across harts.



Machines with long temporal vector registers might benefit from using

less than VLMAX, but this is highly dependent on specifics of the

interaction of the microarchitecture and the scheduled application

kernel (otherwise, the long vector registers were a waste of

resources).  I can't see how to do this portably beyond selecting

VLMAX.



Krste





| Of course, the implementation-defined value must be fixed across all harts, so thread migration doesn't break software.



| Guy



| On Mon, Feb 15, 2021 at 11:30 PM <krste@...> wrote:



|     Replying to old thread to add rationale for current choice.



|||||| On Mon, 21 Dec 2020 13:52:07 -0800, Zalman Stern <zalman@...> said:



|     | Does it get easier if the specification is just the immediate value plus one?



|     No - this costs more gates on critical path.  Mapping 00000 => 32 is

|     simpler in area and delay.



|     | I really don't understand how this encoding is particularly great for immediates as many of the valuhes are likely very rarely or even never used and it

|     seems

|     | like one can't get long enough values even for existing SIMD hardware in some data types. Compare to e.g.:

|     |     (first_bit ? 3 : 1) << rest_of_the_bits

|     | or:

|     |     map[] = { 1, 3, 5, 8 }; // Or maybe something else for 5 and 8

|     |     map[first_two_bits] << rest_of_the_bits;



|     | I.e. get a lot of powers of two, multiples of three-vecs for graphics, maybe something else.



|     As a counter-example for this particular example, one code I looked at

|     recently related to AR/VR used 9 as one dimension.



|     The challenge is agreeing on the best mapping from the 32 immediate

|     encodings to the most commonly used AVL values.



|     More creative mappings do consume some incremental logic and path

|     delay (as well as adding some complexity to software toolchain).

|     While they can provide small gains in some cases, this is offset by

|     small losses in other cases (someone will want AVL=17 somewhere, and

|     it's not clear that say AVL=40 is a substantially better use of

|     encoding).  There is not huge penalty if the immediate does not fit,

|     at most a li instruction, which might be hoisted out of the loop.



|     The curent v0.10 definition uses the obvious mapping of the immediate.

|     Simplicity is a virtue, and any potential gains are small for AVL >

|     31, where most implementation costs are amortized over the longer

|     vector and many implementations won't support longer lengths for a

|     given datatype in any case.



|     Krste



|     | -Z-



|     | On Mon, Dec 21, 2020 at 10:47 AM Guy Lemieux <guy.lemieux@...> wrote:



|     |     for vsetivli, with the uimm=00000 encoding, rather than setting vl to 32, how setting it to some other meaning?



|     |     one option is to set vl=VLMAX. i have some concerns about software using this safely (eg, if VLMAX turns out to be much larger than software

|     anticipated,

|     |     then it would fail; correcting this requires more instructions than just using the regular vsetvl/vsetvli would have used). 



|     |     another option is to allow an implementation-defined vl to be chosen by hardware; this could be anywhere between 1 and VLMAX. for example,

|     implementations

|     |     may just choose vl=32, or they may choose something else. it allows the CPU architect to devise a scheme that best fits the implementation. this may

|     |     consider factors like the effective width of the execution engine, the pipeline depth (to reduce likelihood of stalls from dependent instructions), or

|     |     that the vector register file is actually a multi-level memory hierarchy where some smaller values may operate with greater efficiency (lower power),

|     or

|     |     matching VL to the optimal memory system burst length. perhaps some guidance by the spec could be given here for the default scheme, eg whether the

|     |     implementation optimizes for best performance or power (while still allowing implementations to modify this default via an implementation-defined CSR).

|     |     software using a few extra cycles to check the returned vl against AVL should not a big problem (the simplest solution being vsetvli followed by

|     vsetivli)



|     |     g



|     |     On Fri, Dec 18, 2020 at 6:13 PM Krste Asanovic <krste@...> wrote:



|     |         # vsetivli



|     |         A new variant of vsetvl was proposed providing an immediate as the AVL

|     |         in rs1[4:0].  The immediate encoding is the same as for CSR immediate

|     |         instructions. The instruction would have bit 31:30 = 11 and bits 29:20

|     |         would be encoded same as vsetvli.



|     |         This would be used when AVL was statically known, and known to fit

|     |         inside vector register group.  Compared with existing PoR, it removes

|     |         need to load immediate into a spare scalar register before executing

|     |         vsetvli, and is useful for handling scalar values in vector register

|     |         (vl=1) and other cases where short fixed-sized vectors are the

|     |         datatype (e.g., graphics).



|     |         There was discussion on whether uimm=00000 should represent 32 or be

|     |         reserved.  32 is more useful, but adds a little complexity to

|     |         hardware.



|     |         There was also discussion on whether instruction should set vill if

|     |         selected AVL is not supported, or whether should clip vl to VLMAX as

|     |         with other instructions, or if behavior should be reserved.  Group

|     |         generally favored writing vill to expose software errors.

Replying to old thread to add rationale for current choice.

>>>>> On Mon, 21 Dec 2020 13:52:07 -0800, Zalman Stern <zalman@...> said:

| Does it get easier if the specification is just the immediate value plus one?

No - this costs more gates on critical path.  Mapping 00000 => 32 is
simpler in area and delay.

| I really don't understand how this encoding is particularly great for immediates as many of the valuhes are likely very rarely or even never used and it seems
| like one can't get long enough values even for existing SIMD hardware in some data types. Compare to e.g.:
|     (first_bit ? 3 : 1) << rest_of_the_bits
| or:
|     map[] = { 1, 3, 5, 8 }; // Or maybe something else for 5 and 8
|     map[first_two_bits] << rest_of_the_bits;

| I.e. get a lot of powers of two, multiples of three-vecs for graphics, maybe something else.

As a counter-example for this particular example, one code I looked at
recently related to AR/VR used 9 as one dimension.

The challenge is agreeing on the best mapping from the 32 immediate
encodings to the most commonly used AVL values.

More creative mappings do consume some incremental logic and path
delay (as well as adding some complexity to software toolchain).
While they can provide small gains in some cases, this is offset by
small losses in other cases (someone will want AVL=17 somewhere, and
it's not clear that say AVL=40 is a substantially better use of
encoding).  There is not huge penalty if the immediate does not fit,
at most a li instruction, which might be hoisted out of the loop.

The curent v0.10 definition uses the obvious mapping of the immediate.
Simplicity is a virtue, and any potential gains are small for AVL >
31, where most implementation costs are amortized over the longer
vector and many implementations won't support longer lengths for a
given datatype in any case.

Krste


| -Z-

| On Mon, Dec 21, 2020 at 10:47 AM Guy Lemieux <guy.lemieux@...> wrote:

|     for vsetivli, with the uimm=00000 encoding, rather than setting vl to 32, how setting it to some other meaning?

|     one option is to set vl=VLMAX. i have some concerns about software using this safely (eg, if VLMAX turns out to be much larger than software anticipated,
|     then it would fail; correcting this requires more instructions than just using the regular vsetvl/vsetvli would have used). 

|     another option is to allow an implementation-defined vl to be chosen by hardware; this could be anywhere between 1 and VLMAX. for example, implementations
|     may just choose vl=32, or they may choose something else. it allows the CPU architect to devise a scheme that best fits the implementation. this may
|     consider factors like the effective width of the execution engine, the pipeline depth (to reduce likelihood of stalls from dependent instructions), or
|     that the vector register file is actually a multi-level memory hierarchy where some smaller values may operate with greater efficiency (lower power), or
|     matching VL to the optimal memory system burst length. perhaps some guidance by the spec could be given here for the default scheme, eg whether the
|     implementation optimizes for best performance or power (while still allowing implementations to modify this default via an implementation-defined CSR).
|     software using a few extra cycles to check the returned vl against AVL should not a big problem (the simplest solution being vsetvli followed by vsetivli)

|     g

|     On Fri, Dec 18, 2020 at 6:13 PM Krste Asanovic <krste@...> wrote:

|         # vsetivli

|         A new variant of vsetvl was proposed providing an immediate as the AVL
|         in rs1[4:0].  The immediate encoding is the same as for CSR immediate
|         instructions. The instruction would have bit 31:30 = 11 and bits 29:20
|         would be encoded same as vsetvli.

|         This would be used when AVL was statically known, and known to fit
|         inside vector register group.  Compared with existing PoR, it removes
|         need to load immediate into a spare scalar register before executing
|         vsetvli, and is useful for handling scalar values in vector register
|         (vl=1) and other cases where short fixed-sized vectors are the
|         datatype (e.g., graphics).

|         There was discussion on whether uimm=00000 should represent 32 or be
|         reserved.  32 is more useful, but adds a little complexity to
|         hardware.

|         There was also discussion on whether instruction should set vill if
|         selected AVL is not supported, or whether should clip vl to VLMAX as
|         with other instructions, or if behavior should be reserved.  Group
|         generally favored writing vill to expose software errors.

I attempted to write a sequence that addresses that observation, along with a couple other pedantic details, and posted it to the ticket. 

https://github.com/riscv/riscv-v-spec/issues/623

On Sat, Jan 30, 2021 at 11:37 AM Bill Huffman <huffman@...> wrote:

Krste,



I think the round float to integer as float sequence needs to use vmfle.vf with the usage of the mask inverted.  Otherwise NaN values will use the integer instead of the original NaN.



      Bill



-----Original Message-----

From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic

Sent: Friday, January 29, 2021 8:52 PM

To: tech-vector-ext@...

Subject: [RISC-V] [tech-vector-ext] Vector TG minutes, 2021/1/29



EXTERNAL MAIL







Date: 2021/01/29

Task Group: Vector Extension

Chair: Krste Asanovic

Co-Chair: Roger Espasa

Number of Attendees: ~16

Current issues on github: https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec__;!!EHscmS1ygiU1lA!S65qKyz6MSIPofhHPvb7N7aMd1B9iyvNSfZqcbXAgxL4BM6BEBnR3Y3RZOmaCz8$



# Meetings



Meetings will continue in the regular Friday time slot as given on the task groups' Google calendar.



# v0.10 release



Version v0.10 (zero-point-ten) is tagged in repo, incorporating all specification changes agreed to date.  A numbered version was requested by toolchain folks to help with their release process.  An archived pdf build of v0.10 is available at:



https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec/releases/download/v0.10/riscv-v-spec-0.10.pdf__;!!EHscmS1ygiU1lA!S65qKyz6MSIPofhHPvb7N7aMd1B9iyvNSfZqcbXAgxL4BM6BEBnR3Y3RUN2S-AA$



This version is intended to provide a stable milestone for internal development, but is not ready for public review or ratification.

However, the intent is that there are no substantial changes in instruction specifications before reaching frozen v1.0 status for public review, though of course there cannot be any guarantees.  The repo version name has been updated for the next stage of editing.



Issues discussed:



#623  Round Float to integer as float



The current ISA spec does not have an instruction that rounds a float to an integer but leaving result as a float (IEEE RoundToIntegral*).

The following five vector instruction sequence was quickly proposed, but not checked for correctness or completeness:

    vfcvt.rtz.x.f.v v8, v4     # Round to integer of same width (could use frm)

    vfcvt.f.x.v v8, v8         # Round back to float of same width

    vfabs.f.f.v v12, v4        # Get magnitude of original value.

    vmfgt.vf v0, v4, f0        # Is large integer already? f0 has threshold.

    vmerge.vvm v4, v8, v4, v0  # Leave alone if already an integer



Group was to evaluate correct equivalent sequence and to determine relative importance of supporting the operation directly.



#550 Zve* subsets



There was discussion on the exact composition of the Zve* subsets, though mostly there was agreement with decisions in earlier meetings.

One question is whether multiplies that produce the upper word of a ELEN*ELEN-bit product (vmulh* and vsmul*) should be mandated on all embedded subsets when ELEN>=64.

Krste,



I think the round float to integer as float sequence needs to use vmfle.vf with the usage of the mask inverted.  Otherwise NaN values will use the integer instead of the original NaN.



      Bill



-----Original Message-----

From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic

Sent: Friday, January 29, 2021 8:52 PM

To: tech-vector-ext@...

Subject: [RISC-V] [tech-vector-ext] Vector TG minutes, 2021/1/29



EXTERNAL MAIL







Date: 2021/01/29

Task Group: Vector Extension

Chair: Krste Asanovic

Co-Chair: Roger Espasa

Number of Attendees: ~16

Current issues on github: https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec__;!!EHscmS1ygiU1lA!S65qKyz6MSIPofhHPvb7N7aMd1B9iyvNSfZqcbXAgxL4BM6BEBnR3Y3RZOmaCz8$



# Meetings



Meetings will continue in the regular Friday time slot as given on the task groups' Google calendar.



# v0.10 release



Version v0.10 (zero-point-ten) is tagged in repo, incorporating all specification changes agreed to date.  A numbered version was requested by toolchain folks to help with their release process.  An archived pdf build of v0.10 is available at:



https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec/releases/download/v0.10/riscv-v-spec-0.10.pdf__;!!EHscmS1ygiU1lA!S65qKyz6MSIPofhHPvb7N7aMd1B9iyvNSfZqcbXAgxL4BM6BEBnR3Y3RUN2S-AA$



This version is intended to provide a stable milestone for internal development, but is not ready for public review or ratification.

However, the intent is that there are no substantial changes in instruction specifications before reaching frozen v1.0 status for public review, though of course there cannot be any guarantees.  The repo version name has been updated for the next stage of editing.



Issues discussed:



#623  Round Float to integer as float



The current ISA spec does not have an instruction that rounds a float to an integer but leaving result as a float (IEEE RoundToIntegral*).

The following five vector instruction sequence was quickly proposed, but not checked for correctness or completeness:

    vfcvt.rtz.x.f.v v8, v4     # Round to integer of same width (could use frm)

    vfcvt.f.x.v v8, v8         # Round back to float of same width

    vfabs.f.f.v v12, v4        # Get magnitude of original value.

    vmfgt.vf v0, v4, f0        # Is large integer already? f0 has threshold.

    vmerge.vvm v4, v8, v4, v0  # Leave alone if already an integer



Group was to evaluate correct equivalent sequence and to determine relative importance of supporting the operation directly.



#550 Zve* subsets



There was discussion on the exact composition of the Zve* subsets, though mostly there was agreement with decisions in earlier meetings.

One question is whether multiplies that produce the upper word of a ELEN*ELEN-bit product (vmulh* and vsmul*) should be mandated on all embedded subsets when ELEN>=64.

I was going to restart the vector TG meetings next week (Jan 29), and have a goal of having most pending updates added to the spec a few days before then.

Krste