ELEN to MSEW. Define SMUL and differentiate from LMUL, as done with EMUL.

[David-Horner]

A1 The term ELEN, defined as maximum Element LENgth is actually width. LMUL is conflated in the eco-system. The RFC intrinsics doc, LMUL correctly identifies a VLEN multiplication for elements. However, in the RVV specification, most references are actually to the vtype established LMUL value. A2. Confusion arises when first introduced to these terms. Element width and effective Vector length are closely coupled concepts affecting total usefulness in a given application. When the related definitions and use of these concepts are expressed differently, and at times in contradiction, confusion arrises. (a bad thing for an explanatory document). ELEN is a width not a length and so should be renamed to express its true nature.

A3. SEW might better be called "Selected Element Width", selected as the default value for subsequent vector operations. There really is no "standard". Change ELEN to MSEW, Maximum element Width that can be Selected as default (the standard) value in vtype. LMUL as a specific identifier for a group of (or fraction of ) physical registers is an appropriate use for the acronym. However, given EMUL is use as the Effective MULtiplier in contrast to the Selected ("standard") multiplier, SMUL and vsmul should be the acronyms for physical register multiplier and filed in vtype that encodes it, respectively. MMUL as maximum multiplier value used when needed completes the A4. The commonality of nomenclature ( EEW, SEW and MSEW ; EMUL, SMUL and MMUL) and use (EEW and EMUL; ; SMUL and SEW; MSEW and MMUL) should reduce confusion vs the mismatched width/length nomenclature (ELEN and EEW/SEW) and mixed use domain LMUL vs SEW; MSEW vs ELEN. Although these acronyms are in high use throughout the documents, there is no aliasing of these terms with one another, so a global change will in most cases be correct, with the few situations where the original term is appropriate (LMUL in particular) a moderate to small effort to retain. A5. The already initiated are comfortable with the current abbreviations, nomenclature and inferences. The names are in high use throughout the documents so some tools (like diff ) are going to see substantial physical change even if the conceptual change is readily apparent.

Krste asked me to use this Q&A format: Q1. What is the problem? Q2. What's wrong with what's there now? Q3. What is the solution you're proposing? Q4. How is it better? Q5. How is it worse? So if these posts appear in a stilted, akward , contrived format for the particular subject material, please forgive my deficiencies in working within this framework.

[David-Horner]

I believe the time to make these nomenclature changes is prior to v1.0.

After V1.0 the acronyms will be even more entrenched (although a redefinition to "Selected Element Width" would still be possible.

With the introduction of EEW, Effective Element Width, the SEW standing for "standard" is less troublesome, but only because it waters down the meaning of "standard" , rather than helping describe it.

@kasanovic . I'm willing to do the patches to accomplish this. But, as there is substantial reworking the current doc to remove the explicit SLEN model, is it better for me to wait? Or are you able to both at the same time?

So I would tag this "For V1.0"

[kasanovic]

Let me try to incorporate these changes in v1.0 updates. There is a lot of text to update for SLEN change, and this will take a little time to straighten out.

I agree with SEW = Selected element width, and probably LMUL setting as SMUL

ELEN however ties into XLEN/FLEN/ILEN/VLEN etc. nomenclature for implementation parameters that are in bits, so I don't want to change that.

Regarding MSEW. ELEN is not actually defined as largest SEW setting (though it is also that) - it is the largest type any operation can produce or consume, which adds further constraint on SEW setting.

We have fixed standard LMUL range 1-8 so don't need maximum LMUL (at least, for now).

[David-Horner]

Excellent thank you very much.

The ELEN explanation is good. Can it be incorporated into the definition rather than only

The maximum size of a single vector element in bits, ELEN ≥ 8, which must be a power of 2

perhaps

The width of the largest type any operation can produce or consume; the maximum width of a single vector element in bits. ELEN ≥ 8 and must be a power of 2.

Is it technically a type? Certain types may be limited to smaller values (double and single float) so identifying the largest type is significant. However, conceivably there will be types that are not well described by ELEN. e.g. opaque pointer types, to say a security structure? These might even be variable length elements. Will we redefine ELEN then as only relevant to a single element width (as I suggested above)? Will we likely define another implementation parameter specific to these types, and then add exclusions to the ELEN def as necessary?

Again thank you for addressing this concern.