Krste, Roger We have just released an update of our free riscvOVPsim reference simulator version: 20191217.0 and put it on the https://github.com/riscv/riscv-ovpsim. riscvOVPsim supports the full

Hi,  Anyone know extra designed ABI information (like Calling Convention)    about for vector register ? --Jojo

There is a brief sketch of the Linux vector calling convention here: https://github.com/riscv/riscv-v-spec/blob/master/calling-convention.adoc Note this is the convention for normal C ABI calls; a

Hi,  Thanks for your mention.  It’s so clear & simple, there is no convention for vector args & return of function ?    also, according our long time designed cpu experiments, there should

Vectors are passed in memory and returned in memory. Vectors are arbitrary length, whereas the vector registers are fixed length, and can only be used to temporarily hold a portion of a memory vector.

Some code will not want args in vector regs, so that we don't have to save/restore them around calls. Some code will want args in vector regs, so that they can have subroutines that operate on

Hi,  We met some problems as your mention also.  Consider some code will want args in vector regs, we study from SVE    vregs layout and config our RISCV vregs layout as following:  | v0-7

Providing callee-saved vector registers in the regular C calling convention might actually degrade performance, as most vector computation is done in leaf functions or in strip-mine loops that don't

Oh, heck [*]: Callee saved registers of any form can have bad performance where there is a potential partial register issue. E.g. on an out of order machine with register renaming. Although even

The slideup instruction has this restriction: The destination vector register group for vslideup cannot overlap the source vector register group or the mask register, otherwise an illegal instruction

It's important that the slidedown instruction can overwrite its source operand. Debuggers will use this feature to populate a vector register in-place without clobbering other architectural state.

Hi Andrew, I do not understand your statement. Why is it important? Why is the difference with slideup? The slideup cannot clobber the source operand with destination operand because the

Hi Thang, I think Andrew is suggesting that the vslideup restriction is there to allow some flexibility with implementations. However, one of (vslideup/vslidedown) needs to allow the same source/dest

Thanks Guy for the explanation, but my implementation is both incrementing element index for slideup and decrementing element index for slidedown (which is symmetrical implementation and simplest from

I'm curious why you chose to be symmetrical (no need), and why you decided incrementing for slideup decrementing for slidedn (I would do the opposite). By incrementing for vslidedown, and

Oops, yes, I meant vslide1down. Using vslide1down isn't about performance; it's the only way I know of for the debugger to construct a vector without additional storage. The alternative would have

Date: 2020/1/24 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~20 github: https://github.com/riscv/riscv-v-spec Outstanding items from prior meeting: #362/#354, #341,

In the last meeting, we discussed a problem that would be introduced if we were to drop the fixed-size (b/h/w) variants of the vector load/stores and only have the SEW-size (e) variants. From

Could a fractional LMUL circumvent the constraint that a widening instruction's output register group must be larger than its input register group(s)? --Nick Knight

I'm realizing the idea doesn't quite work unless machine actually stores the fractional LMUL value (to cope with SLEN and widening instruction behavior), and so would need the new instruction and