The aspect that will probably be most problematic for programmer is the loss of memory mapping paradigm. Whereas adjacent bytes in memory are in the same or adjacent words (ditto for half words and do

Yes. The register is not tainted by having been used as fractional. But what I was meaning was that there is no active use of that space during fractional mode. That temporary switch to slidedown can

as some are not on github, I posted this response to #434 here: Observations: - single SEW operations are agnostic to underlying structure (as Krte noted in recent doc revision) - mixed SEW operations

mixed SEW operations (widening & narrowing) have substantial impact on contiguous SLEN=VLEN I read the "SLEN=VLEN" extension as a logical/virtual widening of SLEN to VLEN. The machine behaves as if SL

Then I agree that the risk of software fragmentation is high with such an extension. The reality is that some machines will indeed be SLEN=VLEN and thus risk some fragmentation. I am indeed proposing

In trying to make SEW level interleave by augmenting the instruction set (including casting), I have a few observations. - arithmetic operators need to function at a given SEW and there is no in-memor

Perhaps you would be willing to comment on #410 Place stabler RVV control fields in bits [30:12] of vtype. reduction of VLMAX is not sufficient. Within each SLEN chunk the existing data will already b

Note: To help understand the #423 as the meeting introduction only mentioned transient SEW and LMUL overrides. The proposal is generalized and includes extending modifiers beyond what are mapped by vs

I applaud the ordinal nature of the mask structure that is independent of SEW and LMUL. The problem that I have is the mismatch between units of measure, which is bytes in element lengths and bits in

I would agree that "by definition" this is a sufficient condition to obtain the instructions that Krste was envisioning of instructions the also nop on SLEN=VLEN machine. That is a sufficient conditio

By the way, this is similar to the "prefix" proposal that applies the transform to selected source and/or destinations. The cost is reduced as the "transform" is occurring while the operation is also

Nor was I intending on implying that you believed these casting instructions would affect the memory system. Although Krste and I believe Andrew did suggest the memory side of the register file could

that may be For me the definitions contained in 1,2 and 3 need to be more rigorously defined before I can agree that the constraints/behaviours described are provably inconsistent on aggregate.. This

Correct I don't understand the reason for this constraint. Still not got it. clstr is not a count but a size. When CLSTR is 32 this last row is 7 5 3 1 6 4 2 0 SEW=ELEN=32b If I understood your diagra

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 a range of value

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 compatibility, clstr pr

This is v0.8 with SLEN=8.

I believe this can be weakened to required: select-able distribution patterns that are sufficiently compatible that they avoid fragmenting the software ecosystem.

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 filled. This can lead

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 and methods is enormo