回复：Re: 回复：[RISC-V] [tech-vector-ext] RISC-V Vector Spec version 1.0-rc1-20210608

Guy Lemieux

thanks, I see the api comments now too.

pretty easy to do using vslide1up/dn and vmerge

g

On Tue, Jun 15, 2021 at 2:12 PM David Horner <ds2horner@...> wrote:
@guy: I don't know what each letter stands for, but the link has this:
TRN1 Interleave even elements from two vectors .
I assume there is TRN for odds and maybe mixed?

On Tue, Jun 15, 2021, 03:34 Roger Ferrer Ibanez, <roger.ferrer@...> wrote:

Hi,

I didn't realise this was the private list and Romain is not in

this one. So I'm forwarding his answer on his behalf

There's some sample codes to emulate SVE/NEON-like instructions

using the historical EPI intrinsics (should be mostly

self-explanatory, Roger will definitely know them ) here:

<https://github.com/rdolbeau/EPI-test-codes-vector/blob/master/simplefft16-rvv/vf64.h>

Other subdirectories of the same repo includes integer variants.

Not all functions might work for non-power-of-two length, but

they can be a starting point for some useful pattern.

Cordially,

Hope this helps.

Kind regards,

On 15/6/21 9:08, Roger Ferrer Ibanez

wrote:

Hi,

I agree that computing those indexes is not always trivial

Some ideas you can consider (not claiming these are the most

efficient ways)

• reverse is not too complex: vid.v + vrsub.vx using vl as the

scalar to subtract

• zip is harder: start with the "halved indexes" vid + vsrl.vi

(0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements"

vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a

power of two, shift) with the first index of the second vector

(which maybe is vl/2 in your case). So you get 0, vl/2, 0,

vl/2, 0, vl/2, .... Then add this vector to the halved indexes

so you get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...

• unzip worst of the cases you can reverse what you did for

zip

• trn I don't have any ideas from the top of my head, /cc

Romain Dolbeau who may recall how he worked around the cases

in FFTW where he needed a trn-like operation

Hope this helps.

Kind regards,

On 15/6/21 8:14, Linjie Yu via

lists.riscv.org wrote:

Dear  Craig and Roger,

​    ​Thanks a lot for providing  me  good solutionI have tried them,  they are

all good solutions of
upsample

application.

​    ​ But, when it comes to other applications, such  as zip/unzip, trn，reverse and

so on.  The Index value  is
still difficult to be initialized.

Best Regards

Damon Yu

------------------原始邮件

------------------

Spec version 1.0-rc1-20210608

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you

(logical) shift right 1 bit (vsrl.vi)

would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size

and you don't have to load a materialised value from memory

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via

lists.riscv.org wrote:

Hi, all

I encountered a difficulty of applying

"vrgather" instruction recently.  The details are shown

blow:

The date from source should be duplicated as

pair in a upsample application.

Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]

dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4,

5, 5, 6, 6, 7, 7, 8, 8]

So, my relazation is:

--------------------------------------------------------------------------------------------------

int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5,

5 ........，31，31}；// to be compatibled of all the

VLEN(128 ~ 1024)

vfloat32m2_t data = vundefined_f32m2();

vfloat32m1_t  zero

= ( vfloat32m1_t )vmv_v_i_i32m1(0);

while(length >0)

{

int gvl = vsetvl_e32m1(length);

vuint32m2_t v_index = vle32_v_u32m2(index,

gvl);

vfloat32m1_t src_data = vle32_v_f32m1(src,

gvl);

data = vset_f32m2(data, src_data, 0);

data  = vset_f32m2(data, zero, 1);

vfloat32m2_t res =

vrrgather_vv_f32m2(data, v_index, gvl);

length -=gvl;

src += gvl;

vse32_v_f32m2(out, res, gvl);

dst +=gvl;

}

-----------------------------------------------------------------------------------------------

As shown before, the index data should be

initialized as the max VLEN to make the code  compatibled.

So do all the applications,

that need a constant.

I think it is contrary to

the idea of RISC-V, that one code can run on all the

RISC-V hardware.  Does anyone have a better method

Best Regards

Damon Yu

------------------原始邮件

------------------

Spec version 1.0-rc1-20210608

I've just tagged the first release candidate for v1.0 of the vector

spec in github.  PDF attached below.

I've included the TG agreed updates and handled almost all of the

outstanding issues for v1.0.  Thanks for all the feedback.

I would appreciate if folks could read through the whole thing and

submit PRs for typos and other wording improvements.

I'd like to try and settle most concerns over email if possible, and

assume it'll take a little while for everyone to go through the doc.

I'll tentatively schedule a vector TG meeting on Friday June 25 to go

over issues best dealt with on a call.  I'm hoping we can enter public

review at the same point in time.  Remember, we don't have to reach

agreement on all the issues before starting public review, just be OK

as a group with putting this out for public review.

Krste

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

WARNING / LEGAL TEXT: This message is intended only for the

use of theindividual or entity to which it is addressed and

may containinformation which is privileged, confidential,

proprietary, or exemptfrom disclosure under applicable law. If

you are not the intendedrecipient or the person responsible

for delivering the message to theintended recipient, you are

strictly prohibited from disclosing,distributing, copying, or

in any way using this message. If you havereceived this

communication in error, please notify the sender anddestroy

and delete any copies you may have received.

http://www.bsc.es/disclaimer

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

David Horner

@guy: I don't know what each letter stands for, but the link has this:
TRN1 Interleave even elements from two vectors .
I assume there is TRN for odds and maybe mixed?

On Tue, Jun 15, 2021, 03:34 Roger Ferrer Ibanez, <roger.ferrer@...> wrote:

Hi,

I didn't realise this was the private list and Romain is not in this one. So I'm forwarding his answer on his behalf

There's some sample codes to emulate SVE/NEON-like instructions using the historical EPI intrinsics (should be mostly self-explanatory, Roger will definitely know them ) here:

<https://github.com/rdolbeau/EPI-test-codes-vector/blob/master/simplefft16-rvv/vf64.h>

Other subdirectories of the same repo includes integer variants.

Not all functions might work for non-power-of-two length, but they can be a starting point for some useful pattern.

Cordially,
Hope this helps.

Kind regards,

On 15/6/21 9:08, Roger Ferrer Ibanez wrote:

Hi,

I agree that computing those indexes is not always trivial

Some ideas you can consider (not claiming these are the most efficient ways)

• reverse is not too complex: vid.v + vrsub.vx using vl as the scalar to subtract
• zip is harder: start with the "halved indexes" vid + vsrl.vi (0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements" vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a power of two, shift) with the first index of the second vector (which maybe is vl/2 in your case). So you get 0, vl/2, 0, vl/2, 0, vl/2, .... Then add this vector to the halved indexes so you get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...
• unzip worst of the cases you can reverse what you did for zip
• trn I don't have any ideas from the top of my head, /cc Romain Dolbeau who may recall how he worked around the cases in FFTW where he needed a trn-like operation

Hope this helps.

Kind regards,

On 15/6/21 8:14, Linjie Yu via lists.riscv.org wrote:
Dear  Craig and Roger,

​    ​Thanks a lot for providing  me  good solutionI have tried them,  they are all good solutions of  upsample application.
​    ​ But, when it comes to other applications, such  as zip/unzip, trn，reverse and  so on.  The Index value  is still difficult to be initialized.

Best Regards
Damon Yu

------------------原始邮件 ------------------

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you (logical) shift right 1 bit (vsrl.vi) would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size and you don't have to load a materialised value from memory (you compute it instead).

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via lists.riscv.org wrote:
Hi, all

I encountered a difficulty of applying  "vrgather" instruction recently.  The details are shown blow:
The date from source should be duplicated as pair in a upsample application.
Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]
dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8]
So, my relazation is:
--------------------------------------------------------------------------------------------------
int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5 ........，31，31}；// to be compatibled of all the VLEN(128 ~ 1024)

vfloat32m2_t data = vundefined_f32m2();
vfloat32m1_t  zero = ( vfloat32m1_t )vmv_v_i_i32m1(0);
while(length >0)
{
int gvl = vsetvl_e32m1(length);
vuint32m2_t v_index = vle32_v_u32m2(index, gvl);
vfloat32m1_t src_data = vle32_v_f32m1(src, gvl);
data = vset_f32m2(data, src_data, 0);
data  = vset_f32m2(data, zero, 1);
vfloat32m2_t res = vrrgather_vv_f32m2(data, v_index, gvl);
length -=gvl;
src += gvl;
vse32_v_f32m2(out, res, gvl);
dst +=gvl;
}
-----------------------------------------------------------------------------------------------
As shown before, the index data should be  initialized as the max VLEN to make the code  compatibled.
So do all the applications, that need a constant.
I think it is contrary to the idea of RISC-V, that one code can run on all the RISC-V hardware.  Does anyone have a better method ?

Best Regards
Damon Yu

------------------原始邮件 ------------------

I've just tagged the first release candidate for v1.0 of the vector
spec in github.  PDF attached below.

I've included the TG agreed updates and handled almost all of the
outstanding issues for v1.0.  Thanks for all the feedback.

I would appreciate if folks could read through the whole thing and
submit PRs for typos and other wording improvements.

I'd like to try and settle most concerns over email if possible, and
assume it'll take a little while for everyone to go through the doc.

I'll tentatively schedule a vector TG meeting on Friday June 25 to go
over issues best dealt with on a call.  I'm hoping we can enter public
review at the same point in time.  Remember, we don't have to reach
agreement on all the issues before starting public review, just be OK
as a group with putting this out for public review.

Krste

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

WARNING / LEGAL TEXT: This message is intended only for the use of theindividual or entity to which it is addressed and may containinformation which is privileged, confidential, proprietary, or exemptfrom disclosure under applicable law. If you are not the intendedrecipient or the person responsible for delivering the message to theintended recipient, you are strictly prohibited from disclosing,distributing, copying, or in any way using this message. If you havereceived this communication in error, please notify the sender anddestroy and delete any copies you may have received.

http://www.bsc.es/disclaimer
```--
Roger Ferrer Ibáñez - roger.ferrer@...
Barcelona Supercomputing Center - Centro Nacional de Supercomputación```
```--
Roger Ferrer Ibáñez - roger.ferrer@...
Barcelona Supercomputing Center - Centro Nacional de Supercomputación```

Roger Ferrer Ibanez

Hi,

I didn't realise this was the private list and Romain is not in this one. So I'm forwarding his answer on his behalf

There's some sample codes to emulate SVE/NEON-like instructions using the historical EPI intrinsics (should be mostly self-explanatory, Roger will definitely know them ) here:

<https://github.com/rdolbeau/EPI-test-codes-vector/blob/master/simplefft16-rvv/vf64.h>

Other subdirectories of the same repo includes integer variants.

Not all functions might work for non-power-of-two length, but they can be a starting point for some useful pattern.

Cordially,
Hope this helps.

Kind regards,

On 15/6/21 9:08, Roger Ferrer Ibanez wrote:

Hi,

I agree that computing those indexes is not always trivial

Some ideas you can consider (not claiming these are the most efficient ways)

• reverse is not too complex: vid.v + vrsub.vx using vl as the scalar to subtract
• zip is harder: start with the "halved indexes" vid + vsrl.vi (0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements" vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a power of two, shift) with the first index of the second vector (which maybe is vl/2 in your case). So you get 0, vl/2, 0, vl/2, 0, vl/2, .... Then add this vector to the halved indexes so you get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...
• unzip worst of the cases you can reverse what you did for zip
• trn I don't have any ideas from the top of my head, /cc Romain Dolbeau who may recall how he worked around the cases in FFTW where he needed a trn-like operation

Hope this helps.

Kind regards,

On 15/6/21 8:14, Linjie Yu via lists.riscv.org wrote:
Dear  Craig and Roger,

​    ​Thanks a lot for providing  me  good solutionI have tried them,  they are all good solutions of  upsample application.
​    ​ But, when it comes to other applications, such  as zip/unzip, trn，reverse and  so on.  The Index value  is still difficult to be initialized.

Best Regards
Damon Yu

------------------原始邮件 ------------------

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you (logical) shift right 1 bit (vsrl.vi) would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size and you don't have to load a materialised value from memory (you compute it instead).

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via lists.riscv.org wrote:
Hi, all

I encountered a difficulty of applying  "vrgather" instruction recently.  The details are shown blow:
The date from source should be duplicated as pair in a upsample application.
Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]
dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8]
So, my relazation is:
--------------------------------------------------------------------------------------------------
int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5 ........，31，31}；// to be compatibled of all the VLEN(128 ~ 1024)

vfloat32m2_t data = vundefined_f32m2();
vfloat32m1_t  zero = ( vfloat32m1_t )vmv_v_i_i32m1(0);
while(length >0)
{
int gvl = vsetvl_e32m1(length);
vuint32m2_t v_index = vle32_v_u32m2(index, gvl);
vfloat32m1_t src_data = vle32_v_f32m1(src, gvl);
data = vset_f32m2(data, src_data, 0);
data  = vset_f32m2(data, zero, 1);
vfloat32m2_t res = vrrgather_vv_f32m2(data, v_index, gvl);
length -=gvl;
src += gvl;
vse32_v_f32m2(out, res, gvl);
dst +=gvl;
}
-----------------------------------------------------------------------------------------------
As shown before, the index data should be  initialized as the max VLEN to make the code  compatibled.
So do all the applications, that need a constant.
I think it is contrary to the idea of RISC-V, that one code can run on all the RISC-V hardware.  Does anyone have a better method ?

Best Regards
Damon Yu

------------------原始邮件 ------------------

I've just tagged the first release candidate for v1.0 of the vector
spec in github.  PDF attached below.

I've included the TG agreed updates and handled almost all of the
outstanding issues for v1.0.  Thanks for all the feedback.

I would appreciate if folks could read through the whole thing and
submit PRs for typos and other wording improvements.

I'd like to try and settle most concerns over email if possible, and
assume it'll take a little while for everyone to go through the doc.

I'll tentatively schedule a vector TG meeting on Friday June 25 to go
over issues best dealt with on a call.  I'm hoping we can enter public
review at the same point in time.  Remember, we don't have to reach
agreement on all the issues before starting public review, just be OK
as a group with putting this out for public review.

Krste

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

WARNING / LEGAL TEXT: This message is intended only for the use of theindividual or entity to which it is addressed and may containinformation which is privileged, confidential, proprietary, or exemptfrom disclosure under applicable law. If you are not the intendedrecipient or the person responsible for delivering the message to theintended recipient, you are strictly prohibited from disclosing,distributing, copying, or in any way using this message. If you havereceived this communication in error, please notify the sender anddestroy and delete any copies you may have received.

http://www.bsc.es/disclaimer
```--
Roger Ferrer Ibáñez - roger.ferrer@...
Barcelona Supercomputing Center - Centro Nacional de Supercomputación```
```--
Roger Ferrer Ibáñez - roger.ferrer@...
Barcelona Supercomputing Center - Centro Nacional de Supercomputación```

Guy Lemieux

for zip, you don’t need to use vrgather. instead, use vector widening (eg vwaddu with x0) to double the element size (ensuring the MSBs are 0) for one half of the set.
apply vslide1up and widening to the second set, then add the two sets (using original SEW).

for unzip, you can do the reverse. use narrowing for one half and vslide1dn (in SEW/2) + narrowing for the other half.

sorry, what is trn?

g

On Tue, Jun 15, 2021 at 12:08 AM Roger Ferrer Ibanez <roger.ferrer@...> wrote:

Hi,

I agree that computing those indexes is not always trivial

Some ideas you can consider (not claiming these are the most

efficient ways)

• reverse is not too complex: vid.v + vrsub.vx using vl as the

scalar to subtract

• zip is harder: start with the "halved indexes" vid + vsrl.vi

(0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements"

vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a

power of two, shift) with the first index of the second vector

(which maybe is vl/2 in your case). So you get 0, vl/2, 0, vl/2,

0, vl/2, .... Then add this vector to the halved indexes so you

get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...

• unzip worst of the cases you can reverse what you did for zip

• trn I don't have any ideas from the top of my head, /cc Romain

Dolbeau who may recall how he worked around the cases in FFTW

where he needed a trn-like operation

Hope this helps.

Kind regards,

On 15/6/21 8:14, Linjie Yu via

lists.riscv.org wrote:

Dear  Craig and Roger,

​    ​Thanks a lot for providing  me  good

solutionI have tried them,  they are all good solutions of

upsample application.

​    ​ But, when it comes to other applications, such  as zip/unzip,

trn，reverse and  so on.  The Index value  is
still difficult to be initialized.

Best Regards

Damon Yu

------------------原始邮件

------------------

Spec version 1.0-rc1-20210608

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you

(logical) shift right 1 bit (vsrl.vi)

would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size and

you don't have to load a materialised value from memory (you

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via

lists.riscv.org wrote:

Hi, all

I encountered a difficulty of applying

"vrgather" instruction recently.  The details are shown blow:

The date from source should be duplicated as pair

in a upsample application.

Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]

dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5,

5, 6, 6, 7, 7, 8, 8]

So, my relazation is:

--------------------------------------------------------------------------------------------------

int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5

........，31，31}；// to be compatibled of all the VLEN(128

~ 1024)

vfloat32m2_t data = vundefined_f32m2();

vfloat32m1_t  zero =

( vfloat32m1_t )vmv_v_i_i32m1(0);

while(length >0)

{

int gvl = vsetvl_e32m1(length);

vuint32m2_t v_index = vle32_v_u32m2(index,

gvl);

vfloat32m1_t src_data = vle32_v_f32m1(src,

gvl);

data = vset_f32m2(data, src_data, 0);

data  = vset_f32m2(data, zero, 1);

vfloat32m2_t res =

vrrgather_vv_f32m2(data, v_index, gvl);

length -=gvl;

src += gvl;

vse32_v_f32m2(out, res, gvl);

dst +=gvl;

}

-----------------------------------------------------------------------------------------------

As shown before, the index data should be

initialized as the max VLEN to make the code  compatibled.

So do all the

applications, that need a constant.

I think it is

contrary to the idea of RISC-V, that one code can run

on all the RISC-V hardware.  Does anyone have a better

method ?

Best Regards

Damon Yu

------------------原始邮件

------------------

version 1.0-rc1-20210608

I've just tagged the first release candidate for v1.0 of the vector

spec in github.  PDF attached below.

I've included the TG agreed updates and handled almost all of the

outstanding issues for v1.0.  Thanks for all the feedback.

I would appreciate if folks could read through the whole thing and

submit PRs for typos and other wording improvements.

I'd like to try and settle most concerns over email if possible, and

assume it'll take a little while for everyone to go through the doc.

I'll tentatively schedule a vector TG meeting on Friday June 25 to go

over issues best dealt with on a call.  I'm hoping we can enter public

review at the same point in time.  Remember, we don't have to reach

agreement on all the issues before starting public review, just be OK

as a group with putting this out for public review.

Krste

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

WARNING / LEGAL TEXT: This message is intended only for the use

of theindividual or entity to which it is addressed and may

containinformation which is privileged, confidential,

proprietary, or exemptfrom disclosure under applicable law. If

you are not the intendedrecipient or the person responsible for

delivering the message to theintended recipient, you are

strictly prohibited from disclosing,distributing, copying, or in

any way using this message. If you havereceived this

communication in error, please notify the sender anddestroy and

delete any copies you may have received.

http://www.bsc.es/disclaimer

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

Roger Ferrer Ibanez

Hi,

I agree that computing those indexes is not always trivial

Some ideas you can consider (not claiming these are the most efficient ways)

• reverse is not too complex: vid.v + vrsub.vx using vl as the scalar to subtract
• zip is harder: start with the "halved indexes" vid + vsrl.vi (0, 0, 1, 1, 2, 2, 3, 3, ...) then compute the "even elements" vector (0, 1, 0, 1, 0, 1, ...) and then multiply it (or if a power of two, shift) with the first index of the second vector (which maybe is vl/2 in your case). So you get 0, vl/2, 0, vl/2, 0, vl/2, .... Then add this vector to the halved indexes so you get 0, vl/2, 1, 1+vl/2, 2, 2+vl/2, ...
• unzip worst of the cases you can reverse what you did for zip
• trn I don't have any ideas from the top of my head, /cc Romain Dolbeau who may recall how he worked around the cases in FFTW where he needed a trn-like operation

Hope this helps.

Kind regards,

On 15/6/21 8:14, Linjie Yu via lists.riscv.org wrote:
Dear  Craig and Roger,

​    ​Thanks a lot for providing  me  good solutionI have tried them,  they are all good solutions of  upsample application.
​    ​ But, when it comes to other applications, such  as zip/unzip, trn，reverse and  so on.  The Index value  is still difficult to be initialized.

Best Regards
Damon Yu

------------------原始邮件 ------------------

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you (logical) shift right 1 bit (vsrl.vi) would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size and you don't have to load a materialised value from memory (you compute it instead).

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via lists.riscv.org wrote:
Hi, all

I encountered a difficulty of applying  "vrgather" instruction recently.  The details are shown blow:
The date from source should be duplicated as pair in a upsample application.
Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]
dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8]
So, my relazation is:
--------------------------------------------------------------------------------------------------
int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5 ........，31，31}；// to be compatibled of all the VLEN(128 ~ 1024)

vfloat32m2_t data = vundefined_f32m2();
vfloat32m1_t  zero = ( vfloat32m1_t )vmv_v_i_i32m1(0);
while(length >0)
{
int gvl = vsetvl_e32m1(length);
vuint32m2_t v_index = vle32_v_u32m2(index, gvl);
vfloat32m1_t src_data = vle32_v_f32m1(src, gvl);
data = vset_f32m2(data, src_data, 0);
data  = vset_f32m2(data, zero, 1);
vfloat32m2_t res = vrrgather_vv_f32m2(data, v_index, gvl);
length -=gvl;
src += gvl;
vse32_v_f32m2(out, res, gvl);
dst +=gvl;
}
-----------------------------------------------------------------------------------------------
As shown before, the index data should be  initialized as the max VLEN to make the code  compatibled.
So do all the applications, that need a constant.
I think it is contrary to the idea of RISC-V, that one code can run on all the RISC-V hardware.  Does anyone have a better method ?

Best Regards
Damon Yu

------------------原始邮件 ------------------

I've just tagged the first release candidate for v1.0 of the vector
spec in github.  PDF attached below.

I've included the TG agreed updates and handled almost all of the
outstanding issues for v1.0.  Thanks for all the feedback.

I would appreciate if folks could read through the whole thing and
submit PRs for typos and other wording improvements.

I'd like to try and settle most concerns over email if possible, and
assume it'll take a little while for everyone to go through the doc.

I'll tentatively schedule a vector TG meeting on Friday June 25 to go
over issues best dealt with on a call.  I'm hoping we can enter public
review at the same point in time.  Remember, we don't have to reach
agreement on all the issues before starting public review, just be OK
as a group with putting this out for public review.

Krste

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

WARNING / LEGAL TEXT: This message is intended only for the use of theindividual or entity to which it is addressed and may containinformation which is privileged, confidential, proprietary, or exemptfrom disclosure under applicable law. If you are not the intendedrecipient or the person responsible for delivering the message to theintended recipient, you are strictly prohibited from disclosing,distributing, copying, or in any way using this message. If you havereceived this communication in error, please notify the sender anddestroy and delete any copies you may have received.

http://www.bsc.es/disclaimer
```--
Roger Ferrer Ibáñez - roger.ferrer@...
Barcelona Supercomputing Center - Centro Nacional de Supercomputación```

Linjie Yu

Dear  Craig and Roger,

​    ​Thanks a lot for providing  me  good solutionI have tried them,  they are all good solutions of  upsample application.
​    ​ But, when it comes to other applications, such  as zip/unzip, trn，reverse and  so on.  The Index value  is still difficult to be initialized.

Best Regards
Damon Yu

------------------原始邮件 ------------------

Hi Linjie,

I'm not sure I understood your question. I think a vid.v (with a vl of your choice) that then you (logical) shift right 1 bit (vsrl.vi) would generate an index like the one you have now the "index[]" array.

This looks like it does not require to hardcode any size and you don't have to load a materialised value from memory (you compute it instead).

Hope this helps.

Kind regards,

On 11/6/21 9:22, Linjie Yu via lists.riscv.org wrote:
Hi, all

I encountered a difficulty of applying  "vrgather" instruction recently.  The details are shown blow:
The date from source should be duplicated as pair in a upsample application.
Eg:  src = [0, 1, 2, 3, 4, 5, 6, 7, 8]
dst =  [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8]
So, my relazation is:
--------------------------------------------------------------------------------------------------
int inex[64] = {0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5 ........，31，31}；// to be compatibled of all the VLEN(128 ~ 1024)

vfloat32m2_t data = vundefined_f32m2();
vfloat32m1_t  zero = ( vfloat32m1_t )vmv_v_i_i32m1(0);
while(length >0)
{
int gvl = vsetvl_e32m1(length);
vuint32m2_t v_index = vle32_v_u32m2(index, gvl);
vfloat32m1_t src_data = vle32_v_f32m1(src, gvl);
data = vset_f32m2(data, src_data, 0);
data  = vset_f32m2(data, zero, 1);
vfloat32m2_t res = vrrgather_vv_f32m2(data, v_index, gvl);
length -=gvl;
src += gvl;
vse32_v_f32m2(out, res, gvl);
dst +=gvl;
}
-----------------------------------------------------------------------------------------------
As shown before, the index data should be  initialized as the max VLEN to make the code  compatibled.
So do all the applications, that need a constant.
I think it is contrary to the idea of RISC-V, that one code can run on all the RISC-V hardware.  Does anyone have a better method ?

Best Regards
Damon Yu

------------------原始邮件 ------------------

I've just tagged the first release candidate for v1.0 of the vector
spec in github.  PDF attached below.

I've included the TG agreed updates and handled almost all of the
outstanding issues for v1.0.  Thanks for all the feedback.

I would appreciate if folks could read through the whole thing and
submit PRs for typos and other wording improvements.

I'd like to try and settle most concerns over email if possible, and
assume it'll take a little while for everyone to go through the doc.

I'll tentatively schedule a vector TG meeting on Friday June 25 to go
over issues best dealt with on a call.  I'm hoping we can enter public
review at the same point in time.  Remember, we don't have to reach
agreement on all the issues before starting public review, just be OK
as a group with putting this out for public review.

Krste

`-- Roger Ferrer Ibáñez - roger.ferrer@...Barcelona Supercomputing Center - Centro Nacional de Supercomputación`

WARNING / LEGAL TEXT: This message is intended only for the use of theindividual or entity to which it is addressed and may containinformation which is privileged, confidential, proprietary, or exemptfrom disclosure under applicable law. If you are not the intendedrecipient or the person responsible for delivering the message to theintended recipient, you are strictly prohibited from disclosing,distributing, copying, or in any way using this message. If you havereceived this communication in error, please notify the sender anddestroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

 1 - 6 of 6