Reminder we have our TG meeting this Friday morning. Details on member calendar. Krste

Guy, FPGA energy/power data is not really relevant to general purpose ISA design, unless your goal is to design an ISA only for soft FPGA cores like Nios or MicroBlaze. Please, take a look at the

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,

Code bloat is important - not just the number load and store instructions but also additional vsetvl/i instructions. This was one of the reasons for vle8, vle16 and others. LMUL>1 is also great for

I made this into its own thread as well. I think there is a parallel in the in-register/in-memory issue and memory consistency model/methods. The complexity of consistency models

I seem to recall that at some point LMUL was only a suggestion and that if the requested vl was short (e.g. the last strip-mining loop on a long application vector) the vsetvl[i] instruction was free

I have some suggestions for the reasons for moving from v0.8 vertical striping to v0.9 horizontal SLEN (interleave) Under v0.8 A) when vl < VLEN/SEW*LMUL the top elements are not

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

On 2020-05-27 7:58 p.m., Guy Lemieux wrote: I believe this can be weakened to required: select-able distribution patterns that are sufficiently compatible that they

Hi Guy, Thanks for your reply. I'll leave a few quick responses, and would like to hear opinions from others on the task group. Agreed. Agreed, especially regarding code storage. When loop

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

I appreciate this discussion about making things friendlier to software. I've always felt the constraints on SLEN-agnostic software to be a nuisance, albeit a mild one. However, I do have a concern

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

This is v0.8 with SLEN=8.

for those not on Github I posted this to #461: CLSTR can be considered a progressive SLEN=VLEN switch. Rather than all or nothing as the SLEN=VLEN switch provides for in-memory

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

Hi all, I was wondering if the group has considered before (and rejected) the following register layout proposal. In this scheme, there is no SLEN parameter, instead the layout is solely defined by

I appreciate your agreement with my analysis, Krste. However, I wasn't drawing a conclusion. I lean toward the conclusion that we keep the "new v0.9 scheme" below and live with casts. But I

for those not on Github I posted this to #461: I gather what was missing from this were examples. I prefer to consider clstr as a dynamic parameter, that some implementations will use