31.4V III: Mapping Elements to Register State

Part III Linux boot: recommended Vol. I (Unprivileged) pp. 288–291 · ~2 min read

Where exactly does element i live? The mapping rules are chosen for software simplicity — elements pack least-significant-byte-first, in order — with an explicit license for hardware to secretly rearrange.

The mapping rules (bytes drawn right-to-left, little-endian within elements)
Rule & example
LMUL = 1Elements pack in order from least- to most-significant bits: VLEN=128, SEW=32 → elements 0,1,2,3 at bytes 3:0, 7:4, B:8, F:C.
LMUL < 1Only the first LMUL·VLEN/SEW elements exist, in the LOW part of the register; the rest is tail (vta applies). VLEN=128, LMUL=1/4, SEW=8 → elements 0-3 in bytes 3:0.
LMUL > 1Fill the lowest-numbered register completely, then continue in the next: VLEN=128, SEW=32, LMUL=2 → elements 0-3 in v2n, 4-7 in v2n+1.
Mask registersONE register, one bit per element: the mask bit for element i is bit i, independent of SEW and LMUL — masks made at any width gate any width.
Dotted-underlined cells have explanations — click one.

Mixed-width loops: hold SEW/LMUL constant

The recommended strategy for loops touching multiple element widths: scale LMUL with the width so SEW/LMUL — and therefore VLMAX — stays constant. At VLEN=128 with SEW/LMUL=16: bytes ride at LMUL=1/2, halfwords at LMUL=1, words at LMUL=2, doublewords at LMUL=4 — all eight elements positionally aligned, so widening operations need no shuffles. The spec’s operating-point table is exactly this: each column a constant SEW/LMUL, each row the LMUL that puts a width into that column. Fractional LMUL is what makes the narrow rows fit in single registers, keeping all 32 names free.

Hardware Designer Notes

For a lane-based design, the mapping decision is where SLEN-style striping debates live (v1.0 settled on the in-order model after long debate — earlier drafts had a visible SLEN parameter). Internal rearrangement buys back the wiring; the write-EEW tag is the price.

Minimal Linux-boot hart MUST

  • Preserve the architectural byte mapping at every observation point (stores, element moves, whole-register ops) whatever internal layout you use
  • Implement the mask bit-i-for-element-i geometry exactly — it is the invariant that makes cross-SEW masking work

MAY simplify / trap-and-emulate

  • Track per-register write-EEW and lazily rescramble on mismatched-EEW reads (the spec’s own suggestion for wide datapaths)
  • Store LMUL>1 groups as physically striped lanes — invisible as long as element order externally holds

Check yourself — element mapping

1.With VLEN=128, SEW=32, LMUL=2 on group v2n/v2n+1, where does element 5 live?

2.Where is the mask bit for element 9, and why doesn't the answer depend on SEW or LMUL?

3.Why does the recommended mixed-width strategy keep SEW/LMUL constant?

3 questions