
Re: 64bit instruction encoding wish list
My current "long instruction encoding" proposal has an example encoding for 64bit V extension
My current "long instruction encoding" proposal has an example encoding for 64bit V extension

By
Claire Wolf <claire@...>
·
#45
·


Re: 64bit instruction encoding wish list
Hi all,
I am not sure if these require 64bit encoding, but I am interested in extended data types, especially signedintegercomplex, singleprecision floatingpoint complex, and unums.
Hi all,
I am not sure if these require 64bit encoding, but I am interested in extended data types, especially signedintegercomplex, singleprecision floatingpoint complex, and unums.

By
Richard Newell
·
#44
·


Re: Vector Indexed Loads  Partial Return?
Anecdote:
One of my initial inspirations for working on dynamic out of order scheduling was to support incremental time pipeline vectors, both scatter/gather and stride.
I.e. the P6 RS began
Anecdote:
One of my initial inspirations for working on dynamic out of order scheduling was to support incremental time pipeline vectors, both scatter/gather and stride.
I.e. the P6 RS began

By
Andy Glew Si5
·
#43
·


Re: Vector Indexed Loads  Partial Return?
Since this is happening to an alreadyslow memory access, I would
guess performing checks in software would be the better way to go.
There is no current talk about aborting a longrunning indexed
Since this is happening to an alreadyslow memory access, I would
guess performing checks in software would be the better way to go.
There is no current talk about aborting a longrunning indexed

By
Guy Lemieux
·
#42
·


Vector Indexed Loads  Partial Return?
This observation is a bit of a memory side issue but is tied to vector indexed loading semantics.
The problem that I see is that my address offsets in the vector indexed load instruction are rather
This observation is a bit of a memory side issue but is tied to vector indexed loading semantics.
The problem that I see is that my address offsets in the vector indexed load instruction are rather

By
Nagendra Gulur
·
#41
·


64bit instruction encoding wish list
Guy pointed out to me that, since several V ISAdesign issues have been punted to an eventual 64bit instruction encoding, we should consider recording them somewhere. I've set up the github wiki for
Guy pointed out to me that, since several V ISAdesign issues have been punted to an eventual 64bit instruction encoding, we should consider recording them somewhere. I've set up the github wiki for

By
andrew@...
·
#40
·


Re: A couple of questions about the vector spec
Thank you for the vslide1up suggestion. I might use this with loop unrolling.
Best Regards
Nagendra
Thank you for the vslide1up suggestion. I might use this with loop unrolling.
Best Regards
Nagendra

By
Nagendra Gulur
·
#39
·


Re: A couple of questions about the vector spec
possibly vslide1up after every reduction, producing a vector of
reductions (possibly in backwards order, unless you rearrange your
outer loop order).
I'm not suggesting that you use vrgather to
possibly vslide1up after every reduction, producing a vector of
reductions (possibly in backwards order, unless you rearrange your
outer loop order).
I'm not suggesting that you use vrgather to

By
Guy Lemieux
·
#38
·


Re: A couple of questions about the vector spec
I am not sure I replied right (I hit reply to sender but not sure who I responded to, learning to work with the list). But thanks for quick replies.
1. Yes, understood about the scalar destination
I am not sure I replied right (I hit reply to sender but not sure who I responded to, learning to work with the list). But thanks for quick replies.
1. Yes, understood about the scalar destination

By
Nagendra Gulur
·
#37
·


Re: A couple of questions about the vector spec
Indices must be able to represent general pointers in some cases (e.g. vectorizing (*(x[i]))++ instead of y[x[i]]++), so implicitly scaling the indices causes problems, particularly when misaligned
Indices must be able to represent general pointers in some cases (e.g. vectorizing (*(x[i]))++ instead of y[x[i]]++), so implicitly scaling the indices causes problems, particularly when misaligned

By
andrew@...
·
#36
·


Re: A couple of questions about the vector spec
1. A vector register is deliberately used as the destination of
reductions. If the destination is a scalar register, then tight
coupling between the vector and scalar units would be necessary,
1. A vector register is deliberately used as the destination of
reductions. If the destination is a scalar register, then tight
coupling between the vector and scalar units would be necessary,

By
Guy Lemieux
·
#35
·


A couple of questions about the vector spec
I am developing sparse matrix codes using the vector extension on RISCV32 using SPIKE simulator. Based on my understanding of the spec thus far, I wanted to ask a couple of questions about the spec. I
I am developing sparse matrix codes using the vector extension on RISCV32 using SPIKE simulator. Based on my understanding of the spec thus far, I wanted to ask a couple of questions about the spec. I

By
Nagendra Gulur
·
#34
·


issue #393  Towards a simple fractional LMUL design.
I'm sending out to the correct mailing list a copy of the revised issue #393.
(link: https://github.com/riscv/riscvvspec/issues/393 )
This was
I'm sending out to the correct mailing list a copy of the revised issue #393.
(link: https://github.com/riscv/riscvvspec/issues/393 )
This was

By
David Horner
·
#33
·


Re: [techvectorext] Some proposals
On a context switch, the underlying physical registers that hold spill
values need to be saved/restored to memory, as well as the associated
rs1 values. This means we need extra instructions to
On a context switch, the underlying physical registers that hold spill
values need to be saved/restored to memory, as well as the associated
rs1 values. This means we need extra instructions to

By
Guy Lemieux
·
#32
·


[techvectorext] Feedback on RISCV Vextension (FFTW3 and Chacha20)
We have seen very efficient FFT execution without adding new
instructions, but there is interest in a layer of DSP extension on top
of the base vector ISA. One goal of the EDIV extension would be
We have seen very efficient FFT execution without adding new
instructions, but there is interest in a layer of DSP extension on top
of the base vector ISA. One goal of the EDIV extension would be

By
Krste Asanovic
·
#31
·


[techvectorext] Some proposals
It doesn't look like all these issues were addressed either on mailing
list or on github tracker. In general, it is much better to split
feedback into individual topics. I'm responding allinone
It doesn't look like all these issues were addressed either on mailing
list or on github tracker. In general, it is much better to split
feedback into individual topics. I'm responding allinone

By
Krste Asanovic
·
#30
·


Re: Minutes of 2020/3/6 vector task group meeting
 On 3/6/20 6:22 PM, Krste Asanovic wrote:
[...]
 #367 Tail Agnostic
 The discussion reviewed the proposal that long temporal vector
 registers with renaming could be handled using vector length
 On 3/6/20 6:22 PM, Krste Asanovic wrote:
[...]
 #367 Tail Agnostic
 The discussion reviewed the proposal that long temporal vector
 registers with renaming could be handled using vector length

By
Krste Asanovic
·
#29
·


Re: Minutes of 2020/3/6 vector task group meeting
...
We've discussed before, but allowing the *agnostic options means code
can be written and tested on an implementation that supports them and
then fail on an implementation that maps them to #1.
...
We've discussed before, but allowing the *agnostic options means code
can be written and tested on an implementation that supports them and
then fail on an implementation that maps them to #1.

By
Bill Huffman
·
#28
·


Minutes of 2020/3/6 vector task group meeting
Date: 2020/3/6
Task Group: Vector Extension
Chair: Krste Asanovic
Number of Attendees: ~21
Current issues on github: https://github.com/riscv/riscvvspec
Note, the Zoom meeting details have changed.
Date: 2020/3/6
Task Group: Vector Extension
Chair: Krste Asanovic
Number of Attendees: ~21
Current issues on github: https://github.com/riscv/riscvvspec
Note, the Zoom meeting details have changed.

By
Krste Asanovic
·
#27
·


Reminder vector TG meeting Friday March 6th, details on members calendar <eom>
By
Krste Asanovic
·
#26
·
