tech-vector-ext@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: [RISC-V] [tech-*] STRATEGIC FEATURE COEXISTANCE was:([tech-fast-int] usefulness of PUSHINT/POPINT from [tech-code-size])

Are we talking about something that is effectively bank switching the opcodes here? Something like that was proposed very early on, using a CSR (like MISA maybe - the details are lost to me) to enable

By Allen Baum · #487 ·

Re: change "raise illegal instruction" -> "reserved" for static encodings

There is text in some places stating this, but it is also something that needs to get reemphasized in the base ISA manual intro. Krste

By Krste Asanovic · #486 ·

Re: change "raise illegal instruction" -> "reserved" for static encodings

Did you keep/add text encouraging implementations to indeed raise illegal on reserved encodings ? I went through the patch (rather quickly) and did not see it. Roger

By Roger Espasa · #485 ·

change "raise illegal instruction" -> "reserved" for static encodings

I'm working through updates to vector spec, and one part of clean up is changing text where it has mandatory raising of illegal instruction exceptions on unsupported encodings to instead state the

By Krste Asanovic · #484 ·

Vector Task Group minutes, 2020/10/23

Reminder: No meeting next Friday October 30. Date: 2020/10/23 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~12 Current issues on github:

By Krste Asanovic · #483 ·

Re: [RISC-V] [tech-*] STRATEGIC FEATURE COEXISTANCE was:([tech-fast-int] usefulness of PUSHINT/POPINT from [tech-code-size])

These are all important considerations. However, what they have in common when considering Allen's question: is that they are all tactical considerations are in the

By David Horner · #482 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

On 2020-10-21 6:33 p.m., swallach wrote: https://github.com/riscv/riscv-v-spec/issues/587#issuecomment-711087236 To clarify, Andrew's reading of the spec has vstart>= vl

By David Horner · #481 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

i have not totally been following this discussion. but at convex we handled this very simply if Vl = 0, no vector operation was executed, and the vector instruction was executed and sequential

By swallach · #480 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

- [tech-cmo] so they don't get bothered with this off-topic discussion | [DH]: I see this openness/lack of arbitrary constraint as precisely the strength of RISCV. | Limiting vector

By krste@... · #479 ·

Re: Sparse Matrix-Vector Multiply (again) and Bit-Vector Compression

Hi Dawei, Unfortunately the V-extension does not currently feature block-matrix multiplication instructions, including the bit-masked versions that you're describing. Some of these operations are

By Nick Knight · #478 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

You're incorrectly characterizing FoF below. The FoF loads are not intended for software to dynamically probe the microarch state to check for possible faults

By David Horner · #477 ·

Vector TG meeting minutes 2020/10/16

Date: 2020/10/16 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~16 Current issues on github: https://github.com/riscv/riscv-v-spec # Definition of

By Krste Asanovic · #476 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

If we allow regular FoF loads to return with vl=0, we must provide a forward-progress guarantee, otherwise the instructions are practically unusable. The forward-progress guarantee must not add

By Krste Asanovic · #475 ·

Re: Sparse Matrix-Vector Multiply (again) and Bit-Vector Compression

Hi， Perhaps instead of using bit vector to encode an entire matrix, we can encode a sub block. There is a common sparse matrix format called BCSR that blocks the non-zero values of CSR, so that we

By lidawei14@... · #474 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

Krste: I gather your answer is more in the context of lr/sc type forward guarantees, instructions that are designed not to trap when delivering on their primary function. So I agree that

By David Horner · #473 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

Sure. You could guarantee forward progress, e.g. by allowing no more than 10 successive "first fault" with VL=0, and requiring trap on element zero on the 11th. That check could be in

By Andy Glew Si5 · #472 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

Here's the strlen example from spec: .text .balign 4 .global strlen # size_t strlen(const char *str) # a0 holds *str strlen: mv a3, a0 # Save

By Krste Asanovic · #471 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

So all the vleff use cases end up then using a vmpopc of some sort to determine the exit condition and never use the trimmed VL ? (other than, of course, to control within the while how many elements

By Roger Espasa · #470 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

I don't think the cases where there was no fault look any different to software than the fault cases. Either can happen anywhere and the while loop may continue. The while loop isn't ended by a

By Bill Huffman · #469 ·

Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)

We're all in agreement that if the spec says "pick where you stop" we'd all pick to trim to VL=3. I was under the impression this was not yet closed (in light of the "stop at cache misses"

By Roger Espasa · #468 ·

401 - 420 of 887

Home Hashtags Subgroups Terms