
Re: Vector element groups
A quick look, and ugh: yet another architectural option unconnected to any opcode or CSR bit that we have to specify to get the correct operation in Sail:
On Thu, Jul 14, 2022 at 10:31 PM Krste
A quick look, and ugh: yet another architectural option unconnected to any opcode or CSR bit that we have to specify to get the correct operation in Sail:
On Thu, Jul 14, 2022 at 10:31 PM Krste

By
Allen Baum
·
#794
·


Vector element groups
I've been working up a scheme to handle vector element groups in
general, with vector crypto being the first anticipated use case.
This replaces the EDIV concept with a more general group concept
I've been working up a scheme to handle vector element groups in
general, with vector crypto being the first anticipated use case.
This replaces the EDIV concept with a more general group concept

By
Krste Asanovic
·
#793
·


Re: I have some questions about the VMADC/VMSBC instructions, thank you for your valuable comments.
It is legal to fill bits vl..VLEN1 with 1s because of the clause that these instructions are always tailagnostic.
It is also legal to compute bits 0..VLMAX1 (as a function of elements 0..VLMAX1),
It is legal to fill bits vl..VLEN1 with 1s because of the clause that these instructions are always tailagnostic.
It is also legal to compute bits 0..VLMAX1 (as a function of elements 0..VLMAX1),

By
Andrew Waterman
·
#792
·


I have some questions about the VMADC/VMSBC instructions, thank you for your valuable comments.
1. Question for tail bits of maskproducing instructions.
In the case of maskproducing instructions, tail elements are the bits with (vl <= bit index < VLEN).So according to riscvvspec1.0, page
1. Question for tail bits of maskproducing instructions.
In the case of maskproducing instructions, tail elements are the bits with (vl <= bit index < VLEN).So according to riscvvspec1.0, page

By
lilei2@...
·
#791
·


Re: Zvediv extension discussions
Sorry, I have followed the thread but COVID kept me busy here.
Zvediv is not strictly needed for matrix multiply. I have to correct Peter Lieber who interpreted that from what we talked at the
Sorry, I have followed the thread but COVID kept me busy here.
Zvediv is not strictly needed for matrix multiply. I have to correct Peter Lieber who interpreted that from what we talked at the

By
Abel Bernabeu
·
#790
·


Re: Zvediv extension discussions
I have serious doubts Zvediv helps with graphics. My previous experience is that trying to force SIMD4 over vectors doesn't really help nor does optimize hardware usage. Every major vendor moved away
I have serious doubts Zvediv helps with graphics. My previous experience is that trying to force SIMD4 over vectors doesn't really help nor does optimize hardware usage. Every major vendor moved away

By
Victor Moya
·
#789
·


Re: Zvediv extension discussions
The current vector TG is only tasked with one more deliverable, which
is the IEEE FP16 halfprecision extensions (Zvfh, Zvfhmin). This is
effectively already defined in ratified specification, and so
The current vector TG is only tasked with one more deliverable, which
is the IEEE FP16 halfprecision extensions (Zvfh, Zvfhmin). This is
effectively already defined in ratified specification, and so

By
Krste Asanovic
·
#788
·


Re: Zvediv extension discussions
Great points Ken & Earl.
One thing I'll point out is that this does not necessarily have much to do with EDIV specifically.
For example, the main goal of EDIV is to support smaller element dot
Great points Ken & Earl.
One thing I'll point out is that this does not necessarily have much to do with EDIV specifically.
For example, the main goal of EDIV is to support smaller element dot

By
Guy Lemieux
·
#787
·


Re: Zvediv extension discussions
Thanks folks, these are all very good points.
Earl: I absolutely agree that these extensions (like all RISCV extensions) need to be developed based on realworld needs and need to be able to show
Thanks folks, these are all very good points.
Earl: I absolutely agree that these extensions (like all RISCV extensions) need to be developed based on realworld needs and need to be able to show

By
Ken Dockser
·
#786
·


Re: Zvediv extension discussions
The AMX extension for AVX512 is an interesting approach....
https://en.wikichip.org/wiki/intel/dl_boost
The AMX extension for AVX512 is an interesting approach....
https://en.wikichip.org/wiki/intel/dl_boost

By
Guy Lemieux
·
#785
·


Re: Zvediv extension discussions
I hope that these discussions will begin with algorithms and applications that need the additional performance, and proceed to analyze how proposed instructions address the greater need.
I hope that these discussions will begin with algorithms and applications that need the additional performance, and proceed to analyze how proposed instructions address the greater need.

By
Earl Killian
·
#784
·


Re: Zvediv extension discussions
In the Graphics/ML SIG, we also discussed matrix operations as well. We talked about a single matrix opcode with various functions like vectormatrix, matrixmatrix, and dot product functions, among
In the Graphics/ML SIG, we also discussed matrix operations as well. We talked about a single matrix opcode with various functions like vectormatrix, matrixmatrix, and dot product functions, among

By
Peter Lieber
·
#783
·


Zvediv extension discussions
I am hearing renewed interest in adding a dotproduct extension to the RISCV Vectors. This includes everything from adding a handful of FP and Int dotproduct instructions all the way to completing
I am hearing renewed interest in adding a dotproduct extension to the RISCV Vectors. This includes everything from adding a handful of FP and Int dotproduct instructions all the way to completing

By
Ken Dockser
·
#782
·


Re: chapter 7.8. Vector Load/Store Segment Instructions
Hello!
As far as I understand, there is no separate field for decoding a segment instruction other than NF. Therefore, those instructions are considered segmented if NFIELDS > 1 (nf != 0).
01.02.2022,
Hello!
As far as I understand, there is no separate field for decoding a segment instruction other than NF. Therefore, those instructions are considered segmented if NFIELDS > 1 (nf != 0).
01.02.2022,

By
Artem Zhdanov
·
#781
·


chapter 7.8. Vector Load/Store Segment Instructions
Hello!
I have a question about vector segment load and stores.
In table 14 we have NFIELDS from 1 to 8.
In paragraphes 7.8.13 we have format like
vlseg<nf>e<eew>.v vd, (rs1),
Hello!
I have a question about vector segment load and stores.
In table 14 we have NFIELDS from 1 to 8.
In paragraphes 7.8.13 we have format like
vlseg<nf>e<eew>.v vd, (rs1),

By
Alexander Podoplelov
·
#780
·


about maskedoff bits for instructions vmsbf.m, vmsif.m, vmsof.m
#defines
Hi，
I have a question about maskedoff bits.
I am not sure what is the behavior of destination inactive maskedoff bits for instructions vmsbf.m, vmsif.m, vmsof.m. Does the "xxxx" means we can fill
Hi，
I have a question about maskedoff bits.
I am not sure what is the behavior of destination inactive maskedoff bits for instructions vmsbf.m, vmsif.m, vmsof.m. Does the "xxxx" means we can fill

By
lilei2@...
·
#779
·


Re: The Width of vcsr and vstart
Thanks for spotting the oversight.
The spec was updated to indicate these should be treated as XLENbit wide registers.
There is no effective difference right now given that upper bits are not
Thanks for spotting the oversight.
The spec was updated to indicate these should be treated as XLENbit wide registers.
There is no effective difference right now given that upper bits are not

By
Krste Asanovic
·
#778
·


Re: [RISCV] [techunprivileged] [RISCV] [techvectorext] FP Trapped exceptions needed for portability
IF the Traponmaskedfflags op isn't executed often, then a 4 instruction sequence
(CSRRD FFLAGS, ANDI, BNE, .+4, ECALL) would do that, so there is a workaround.
IF that has a performance impact,
IF the Traponmaskedfflags op isn't executed often, then a 4 instruction sequence
(CSRRD FFLAGS, ANDI, BNE, .+4, ECALL) would do that, so there is a workaround.
IF that has a performance impact,

By
Allen Baum
·
#777
·


Re: [RISCV] [techunprivileged] [RISCV] [techvectorext] FP Trapped exceptions needed for portability
I'll note that ARM appears to detect tininess before rounding, while
x86 does so after rounding.
Also, current ARM compilers don't support exception trapping on
AArch64.
I'll note that ARM appears to detect tininess before rounding, while
x86 does so after rounding.
Also, current ARM compilers don't support exception trapping on
AArch64.

By
Krste Asanovic
·
#776
·


Re: [RISCV] [techunprivileged] [RISCV] [techvectorext] FP Trapped exceptions needed for portability
Along with this, I'd suggest considering an extension that consists of just
one instruction: trap if (FP flags & mask in instruction) is nonzero. I'm
not a hardware designer, but it seems to me that
Along with this, I'd suggest considering an extension that consists of just
one instruction: trap if (FP flags & mask in instruction) is nonzero. I'm
not a hardware designer, but it seems to me that

By
ghost
·
#775
·
