Thus the compiler when referring to CR0 still generates code that it thinks is scalar and thinks a scalar computation created CR0 but the same code serves double-duty and thus does not need drastic rewrites or modification.
-In concrete terms: when the Vector looping proceeds to increment Integer or FP register numbers linearly, `fp1 fp2 fp3...` when `Rc=1` the Vector of CRs should start at `CR1` just as they do in scalar execution but *not overwrite CR2*. Instead proceed to write to at least 8 or 16 CRs before doing so.
+In concrete terms: when the Vector looping proceeds to increment Integer or FP register numbers linearly, `fp1 fp2 fp3...` when `Rc=1` the Vector of CRs should start at `CR1` for element 0 just as they do in scalar execution but *not overwrite CR2* for element 1.
Two ways in which this may occur: either for numbering to be linear (`CR0..CR127`) but to jump in increments of 8, or to be expressed as sub-numbers similar to FP fractions: `CR1.0 CR1.1 ... CR1.15 CR2.0`. Fractional numbering is more natural and intuitive. The "original" (scalar) CRs 0-7 therefore are interleaved every 16th point in the progression. They are also effectively given a second name: `CR0` is now also named `CR0.0` in effect.
-Here is a table showing progression from 0 to VL-1 when VL=18, should an Integer Vector operation writes first to `CR0`. It is the 16th element before `CR1` is overwritten:
+Here is a table showing progression from 0 to VL-1 when VL=18, where an Integer Vector operation writes first to `CR0` for element 0. It is the 16th element before `CR1` is overwritten:
CRn.0 CR0 0 CR1 16 CR2 CR3 CR4 CR5 CR6 CR7
CRn.1 1 17
projects / libreriscv.git / commitdiff