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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 it is. However, it needn't be, and allowing it to not be gives greater flexibility at minimal cost. This was a suggestion to implement #418. [Introduce vlmt (vl multiplicative threshold) / VLMT Ve

OK. Again thanks. I will generate a few versions and compare incrementally. Will report the anomalies if they show up in your weekend efforts.

First some observations from the revised LMUL. *1 The format for a given SLEN and SEW is the same for all LMUL>=1 *2 LMUL=n is equivalent to LMUL=2 * n with vl < 1/2 vlmax at that level, for n=1,2,4.

Thank you very much for this. I started a pull request, but was including as an extension and still debating the best way to incorporate. Would it be possible to generate a pdf for what is now a subst