Agenda is hopefully clearing up any remaining major issues before 1.0 draft can go out, Krste

I am totally in agreement with Krste. Adding the mask load/store is an improvement but adding the new mask registers is too disruptive and increasing in area. Thanks, Thang

I'm not contemplating changing mask design (yet again) at this point in process. I don't see any great advantage to any of these last round of proposals, as they all have significant downsides for

imho, since are trying to both address the embedded market and the hpc market, we have conflicts wrt logic, power, and cost addressing the hpc market, 8 extra registers for VM, appropriately

In some cases we have widening computations with large LMUL settings, we will quickly run out of v0-v31 if we also have to keep masks in these registers.

Having been a silent observer of this group for what seems like a very long time, but now recently liberated from previous constraints, I will observe that I have seen the use in DSPs of both

One option is to allow mask generating instructions (compares) to write either to regular vector regs or to vmask and to provide move instructions between vector regs and vmask. But mask consuming

i guess i am looking at the wrong set of apps. in any case VM registers NOT in the vector registers permits a robust and performance optimized operations under mask. wrt extra instructions. i am

8 Maks registers are quite needed in modern outer-vectorized loops. Also in graphic shaders. I would say 16 is overkill. Now, and I am not defending this, if we had to go this route, I would

i would also add, that if 8 or 16 registers are needed, why do we only have one register, , V0. if this were true we would need to multi-plex between varius vector registers and V0 i believe i

in my experience only only one maybe two vm registers are needed nested loops under if statements is rare. http://bsc.es/disclaimer

I don’t think a separate mask register will do at all. It would take a mask register file with at least 8 and maybe 16 registers. Lots of compare results need to be kept and operations need to be

i totally agree. if this is done, then instructions like: count bits, etc can directly apply to the mask register. also, from a hardware implementation, the VM register can be implemented

If separate loads and stores are introduced for mask, then separate vmask register can be introduced to avoid dual use of v0 (as a regular vector register and as a mask register) and its

Hi，David Can we see the git of your work? My code has not been upload to git, and I will show it in the mail. Does this mean the 32 vector registers are not enough, or that the

Linjie Yu <linjie.ylj@...> 於 2020年12月11日 週五 下午4:34寫道： Have you consider to use fraction LMUL?

On 2020-12-11 3:34 a.m., Linjie Yu wrote: Can we see the git of your work? Does this mean the 32 vector registers are not enough, or that the number of elements for

Hi，all Recently, I optimized the kernel of GEMM for int8 data. I found that there was no good solution to do in by the use of the present vector ISA. The mainly difficult I meet is: The

I concur. Software can effect tail-undisturbed by A pre conditioning the load, B loading into temp register then use bitwise logic into target, C save last byte of target , lde1, read last byte, write

On the issue of what bits to load for vle1.v, we need to decide whether these are byte loads of length ceil(vl/8) or whether they are bit loads of length vl. Bit loads _can_ have the additional