in terms of overlap with that case — that case normally selects maximally sized AVL. the implied goals there are to make best use of vector register capacity and throughput. l i’m suggesting a case wh

I agree with you. I had suggested the mapping of 00000 to an implementation-defined value (chosen by the CPU architect). For some architectures, this may be 16, for others it may be 32, or even 2. The

for vsetivli, with the uimm=00000 encoding, rather than setting vl to 32, how setting it to some other meaning? one option is to set vl=VLMAX. i have some concerns about software using this safely (eg

I think this is a bad idea for both loads and stores. If the intent is a single load or single store, then there should be another way to do it. Using vector loads/stores with stride=0 is one way to r

Thanks Tim, I think that sums it up nicely. I just wanted to put a pointer out to the original post that I made on isa-dev regarding opcode sharing / management: https://groups.google.com/a/groups.ris

I think a common embedded and FPGA scenarios will be F on the scalar side but no F on the vector side. Adding F to V is nontrivial in area, particularly for FPGAs that lack FPUs, yet an integer-only V

Alex, Keep in mind: a) I amended my proposal to reduce the code bloat identified by Nick b) the effect of the bloat is almost entirely about text segment size, not power or instruction bandwidth, beca

I propose 2 data layouts: memory layout, and internal register group layout. I am not going to specify which internal register group layout to operate upon, because I haven't read the 0.9 spec and don

Nick, thanks for that code snippet, it's really insightful. I have a few comments: a) this is for LMUL=8, the worst-case (most code bloat) b) this would be automatically generated by a compiler, so vi

The precise data layout pattern does not matter. What matters is that a single distribution pattern is agreed upon to avoid fragmenting the software ecosystem. With my additional restriction, the load

As a follow-up, the main goal of LMUL>1 is to get better storage efficiency out of the register file, allowing for slightly higher compute unit utilization. The memory system should not require LMUL>1

I support this scheme, but I would further add a restriction on loads/stores to only support LMUL=1 (no register groups). Instead, any data stored in a registe group with LMUL!=1 must first be “cast”

sorry I wasn’t clear. the data types, eg vint64m1_t, are for data elements. all of the example API definitions also use these same element data types as arguments, but they should be using a data type

well done! can you perhaps explain how the vector operands are to be used/allocated? ie, it appears you wish to use the type system to name vector registers, but there is no limit on these so there mu

my response below is now off-topic, and covers the more flexible reductions wanted by Nagendra. i discourage any further followups here (instead, please search for another recent series of posts by Na

Since this is happening to an already-slow memory access, I would guess performing checks in software would be the better way to go. There is no current talk about aborting a long-running indexed load

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 conver

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, and con

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 iterat

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 decrementing