
Re: 回复：Re: 回复：[RISCV] [techvectorext] RISCV Vector Spec version 1.0rc120210608
thanks, I see the api comments now too.
pretty easy to do using vslide1up/dn and vmerge
g
thanks, I see the api comments now too.
pretty easy to do using vslide1up/dn and vmerge
g

By
Guy Lemieux
·
#650
·


Re: 回复：Re: 回复：[RISCV] [techvectorext] RISCV Vector Spec version 1.0rc120210608
@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?
@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?

By
David Horner
·
#649
·


Re: 回复：Re: 回复：[RISCV] [techvectorext] RISCV Vector Spec version 1.0rc120210608
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
Hope this helps.
Kind regards,
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
Hope this helps.
Kind regards,

By
Roger Ferrer Ibanez
·
#648
·


Re: 回复：Re: 回复：[RISCV] [techvectorext] RISCV Vector Spec version 1.0rc120210608
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
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

By
Guy Lemieux
·
#647
·


Re: 回复：Re: 回复：[RISCV] [techvectorext] RISCV Vector Spec version 1.0rc120210608
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:
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:

By
Roger Ferrer Ibanez
·
#646
·


回复：Re: 回复：[RISCV] [techvectorext] RISCV Vector Spec version 1.0rc120210608
Dear Craig and Roger,
Thanks a lot for providing me goodsolution. I have tried them, they are all good solutions of upsample application.
But, when it comes to other
Dear Craig and Roger,
Thanks a lot for providing me goodsolution. I have tried them, they are all good solutions of upsample application.
But, when it comes to other

By
Linjie Yu
·
#645
·


Background for Policy/Workflow revisions on Github close concern.
Andrew Waterman called Thursday and we discussed many issues including challenges with Issues in Github.
We determined that both were unaware of some relevant aspects [neither of us
Andrew Waterman called Thursday and we discussed many issues including challenges with Issues in Github.
We determined that both were unaware of some relevant aspects [neither of us

By
David Horner
·
#644
·


Re: 回复：[RISCV] [techvectorext] RISCV Vector Spec version 1.0rc120210608
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
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

By
Roger Ferrer Ibanez
·
#643
·


回复：[RISCV] [techvectorext] RISCV Vector Spec version 1.0rc120210608
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.
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.

By
Linjie Yu
·
#642
·


RISCV Vector Spec version 1.0rc120210608
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.
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.

By
Krste Asanovic
·
#641
·


Re: Smaller embedded version of the Vector extension
This is an excellent point, but there are only 8 SSE/AVX/AVX2 registers in 32 bit mode and 16 in 64 bit.
Therefore a 32 bit RISCV could use 32 bit VLEN and LMUL=4 to directly translate SSE code
This is an excellent point, but there are only 8 SSE/AVX/AVX2 registers in 32 bit mode and 16 in 64 bit.
Therefore a 32 bit RISCV could use 32 bit VLEN and LMUL=4 to directly translate SSE code

By
Bruce Hoult
·
#640
·


Re: Smaller embedded version of the Vector extension
If there was no cost, then supporting VLEN=64 on general apps
processor profile would be a good thing to do. But not allowing
standard software to assume VLEN>=128 imposes a nontrivial impact
If there was no cost, then supporting VLEN=64 on general apps
processor profile would be a good thing to do. But not allowing
standard software to assume VLEN>=128 imposes a nontrivial impact

By
Krste Asanovic
·
#639
·


Re: Smaller embedded version of the Vector extension
that's pretty handy, actually. I'm not sure it should be a property of
the V spec itself, rather it could be a requirement that software
which is translated in this method could require an
that's pretty handy, actually. I'm not sure it should be a property of
the V spec itself, rather it could be a requirement that software
which is translated in this method could require an

By
Guy Lemieux
·
#638
·


Re: Smaller embedded version of the Vector extension
"...if written correctly" is precisely the point. If VLEN is specified as >=128, code that targets 128bits explicitly by setting VL to an appropriate constant for a large swath *is* correct. This
"...if written correctly" is precisely the point. If VLEN is specified as >=128, code that targets 128bits explicitly by setting VL to an appropriate constant for a large swath *is* correct. This

By
Zalman Stern
·
#637
·


Re: Smaller embedded version of the Vector extension
If the minimum VLEN is at least 128bits, one can translate NEON/SSE intrinsics directly without having to have every vector instruction dominated by a loop over the vector length.
Z
If the minimum VLEN is at least 128bits, one can translate NEON/SSE intrinsics directly without having to have every vector instruction dominated by a loop over the vector length.
Z

By
Zalman Stern
·
#636
·


Re: Smaller embedded version of the Vector extension
Krste, to be clear,The issue
The RVV spec should be inclusive, rather than exclusive. Setting VLEN
Sorry I wasn't clear. Of course, an implementation with VLEN=64 would
likely be slower than one
Krste, to be clear,The issue
The RVV spec should be inclusive, rather than exclusive. Setting VLEN
Sorry I wasn't clear. Of course, an implementation with VLEN=64 would
likely be slower than one

By
Guy Lemieux
·
#635
·


Re: Smaller embedded version of the Vector extension
Software should still work with VLEN>=64 if written correctly, as it should be VLEN agnostic.
Maybe it should be a recommendation that VLEN>=128, with a minimum of 64 for app processors?
Lower
Software should still work with VLEN>=64 if written correctly, as it should be VLEN agnostic.
Maybe it should be a recommendation that VLEN>=128, with a minimum of 64 for app processors?
Lower

By
Tony Cole
·
#634
·


Re: Smaller embedded version of the Vector extension
This is the requirement for app processors, which are not generally small cores.
Most competing SIMD extensions are at least 128b per vector register.
Lower performance on codes that work well on
This is the requirement for app processors, which are not generally small cores.
Most competing SIMD extensions are at least 128b per vector register.
Lower performance on codes that work well on

By
Krste Asanovic
·
#633
·


Re: Smaller embedded version of the Vector extension
What is the advantage to RVV requiring VLEN >= 128?
I think this should be changed to VLEN >= 64 because:
1) VLEN = 64 is more likely for small implementations; creating a
mandatory expectation to
What is the advantage to RVV requiring VLEN >= 128?
I think this should be changed to VLEN >= 64 because:
1) VLEN = 64 is more likely for small implementations; creating a
mandatory expectation to

By
Guy Lemieux
·
#632
·


Re: Smaller embedded version of the Vector extension
see github issue #550
Krste
see github issue #550
Krste

By
Krste Asanovic
·
#631
·
