-[[!tag standards]]
-
-# SPRs <a name="sprs"></a>
-
-There are five SPRs, available in any privilege level:
-
-* MVL (the Maximum Vector Length)
-* VL (which has different characteristics from standard SPRs)
-* SUBVL (effectively a kind of SIMD)
-* STATE (containing copies of MVL, VL and SUBVL as well as context information)
-* SVSRR0 which is used for exceptions and traps to store SVSTATE.
-
-MVL, VL and SUBVL are only provided for convenience: normally [[sv/setvl]] would be used to obtain a copy of VL, for example.
-
-For Privilege Levels (trap handling) there are the following SPRs,
-where x may be u, s or h for User, Supervisor or Hypervisor
-Modes respectively:
-
-* (x)eSTATE (useful for saving and restoring during context switch,
- and for providing fast transitions)
-
-The u/s SPRs are treated and handled exactly like their (x)epc
-equivalents. On entry to or exit from a privilege level, the contents
-of its (x)eSTATE are swapped with STATE.
-
-# MAXVECTORLENGTH (MVL) <a name="mvl" />
-
-MAXVECTORLENGTH is the same concept as MVL in RVV, except that it
-is variable length and may be dynamically set. MVL is
-however limited to the regfile bitwidth, 64.
-
-# Vector Length (VL) <a name="vl" />
-
-VSETVL is slightly different from RVV. Similar to RVV, VL is set to be within
-the range 0 <= VL <= MVL (where MVL in turn is limited to 1 <= MVL <= XLEN)
-
- VL = rd = MIN(vlen, MVL)
-
-where 1 <= MVL <= XLEN
-
-# SUBVL - Sub Vector Length
+# SPRs <a name="sprs"></a>
-This is a "group by quantity" that effectively asks each iteration
-of the hardware loop to load SUBVL elements of width elwidth at a
-time. Effectively, SUBVL is like a SIMD multiplier: instead of just 1
-operation issued, SUBVL operations are issued.
+The full list of SPRs for Simple-V is:
-The main effect of SUBVL is that predication bits are applied per
-**group**, rather than by individual element. Legal values are 1 to 4.
-Illegal values raise an exception.
+| SPR | Width | Description |
+|---------------|---------|---------------------------------|
+| **SVSTATE** | 64-bit | Zero-Overhead Loop Architectural State |
+| **SVLR** | 64-bit | SVSTATE equivalent of LR-to-PC |
+| **SVSHAPE0** | 32-bit | REMAP Shape 0 |
+| **SVSHAPE1** | 32-bit | REMAP Shape 1 |
+| **SVSHAPE2** | 32-bit | REMAP Shape 2 |
+| **SVSHAPE3** | 32-bit | REMAP Shape 3 |
-# STATE
+Future versions of Simple-V will have at least 7 more SVSTATE SPRs, in a small
+"stack", as part of a full Zero-Overhead Loop Control subsystem.
-This is a standard SPR that contains sufficient information for a
-full context save/restore (see SVSRR0). It contains (and permits setting of):
+## SVSTATE SPR
-* MVL
-* VL
-* dststep - the destination element offset of the current parallel
- instruction being executed
-* srcstep - for twin-predication, the source element offset as well.
-* SUBVL
-* svstep - the subvector element offset of the current
- parallel instruction being executed
-
-The format of the STATE SPR is as follows:
+The format of the SVSTATE SPR is as follows:
| Field | Name | Description |
| ----- | -------- | --------------------- |
-| 0:6 | maxvl | Max Vector Length |
-| 7:13 | vl | Vector Length |
-| 14:20 | srcstep | |
-| 21:27 | dststep | |
-| 28:29 | subvl | |
-| 30:31 | svstep | |
-
-The relationship between SUBVL and the subvl field is:
-
-| SUBVL | (25..24) |
-| ----- | -------- |
-| 1 | 0b00 |
-| 2 | 0b01 |
-| 3 | 0b10 |
-| 4 | 0b11 |
+| 0:6 | maxvl | Max Vector Length |
+| 7:13 | vl | Vector Length |
+| 14:20 | srcstep | for srcstep = 0..VL-1 |
+| 21:27 | dststep | for dststep = 0..VL-1 |
+| 28:29 | dsubstep | for substep = 0..SUBVL-1 |
+| 30:31 | ssubstep | for substep = 0..SUBVL-1 |
+| 32:33 | mi0 | REMAP RA/FRA/BFA SVSHAPE0-3 |
+| 34:35 | mi1 | REMAP RB/FRB/BFB SVSHAPE0-3 |
+| 36:37 | mi2 | REMAP RC/FRT SVSHAPE0-3 |
+| 38:39 | mo0 | REMAP RT/FRT/BF SVSHAPE0-3 |
+| 40:41 | mo1 | REMAP EA/RS/FRS SVSHAPE0-3 |
+| 42:46 | SVme | REMAP enable (RA-RT) |
+| 47:52 | rsvd | reserved |
+| 53 | pack | PACK (srcstep reorder) |
+| 54 | unpack | UNPACK (dststep order) |
+| 55:61 | hphint | Horizontal Hint |
+| 62 | RMpst | REMAP persistence |
+| 63 | vfirst | Vertical First mode |
Notes:
* Setting srcstep, dststep to 64 or greater, or VL or MVL to greater
than 64 is reserved and will cause an illegal instruction trap.
-# SVSRR0
-
-In scalar v3.0B traps, exceptions and interrupts, two SRRs are saved/restored:
-
-* SRR0 to store the PC
-* SRR1 to store a copy of the MSR
-
-Given that SVSTATE is effectively a Sub-PC it is critically important to add saving/restoring of SVSTATE as a full peer equal in status to PC, in every way. At any time PC is saved or restored, so is SVSTATE in **exactly** the same way for **exactly** the same reasons.
-
-The SPR name given for the purposes of saving/restoring SVSTATE is SVSRR0.
+**SVSTATE Fields**
+SVSTATE is a standard SPR that (if REMAP is not activated) contains sufficient
+self-contaned information for a full context save/restore.
+SVSTATE contains (and permits setting of):
+* MVL (the Maximum Vector Length) - declares (statically) how
+ much of a regfile is to be reserved for Vector elements
+* VL - Vector Length
+* dststep - the destination element offset of the current parallel
+ instruction being executed
+* srcstep - for twin-predication, the source element offset as well.
+* ssubstep - the source subvector element offset of the current
+ parallel instruction being executed
+* dsubstep - the destination subvector element offset of the current
+ parallel instruction being executed
+* vfirst - Vertical First mode. srcstep, dststep and substep
+ **do not advance** unless explicitly requested to do so with svstep
+* RMpst - REMAP persistence. REMAP will apply only to the following
+ instruction unless this bit is set, in which case REMAP "persists".
+ Reset (cleared) on use of the `setvl` instruction if used to
+ alter VL or MVL.
+* Pack - if set then srcstep/ssubstep VL/SUBVL loop-ordering is inverted.
+* UnPack - if set then dststep/dsubstep VL/SUBVL loop-ordering is inverted.
+* hphint - Horizontal Parallelism Hint. Indicates that
+ no Hazards exist between groups of elements in sequential multiples of this number
+ (before REMAP). By definition: elements for which `FLOOR(step/hphint)` is
+ equal *before REMAP* are in the same parallelism "group", for both
+ `srcstep` and `dststep`. In Vertical First Mode
+ hardware **MUST** respect Strict Program Order but is permitted to
+ merge multiple scalar loops into parallel batches, if Reservation Station resources
+ are sufficient. Set to zero to indicate "no hint".
+* SVme - REMAP enable bits, indicating which register is to be
+ REMAPed: RA, RB, RC, RT and EA are the canonical (typical) register names
+ associated with each bit, with RA being the LSB and EA being the MSB.
+ See table below for ordering. When `SVme` is zero (0b00000) REMAP
+ is **fully disabled and inactive** regardless of the contents of
+ `SVSTATE`, `mi0-mi2/mo0-mo1`, or the four `SVSHAPEn` SPRs
+* mi0-mi2/mo0-mo1 - these
+ indicate the SVSHAPE (0-3) that the corresponding register (RA etc)
+ should use, as long as the register's corresponding SVme bit is set
+
+Programmer's Note: the fact that REMAP is entirely dormant when `SVme` is zero
+allows establishment of REMAP context well in advance, followed by utilising `svremap`
+at a precise (or the very last) moment. Some implementations may exploit this
+to cache (or take some time to prepare caches) in the background whilst other
+(unrelated) instructions are being executed. This is particularly important to
+bear in mind when using `svindex` which will require hardware to perform (and
+cache) additional GPR reads.
+
+Programmer's Note: when REMAP is activated it becomes necessary on any
+context-switch (Interrupt or Function call) to detect (or know in advance)
+that REMAP is enabled and to additionally explicitly save/restore the four SVSHAPE
+SPRs, SVHAPE0-3. Given that this is expected to be a rare occurrence it was
+deemed unreasonable to burden every context-switch or function call with
+mandatory save/restore of SVSHAPEs, and consequently it is a *callee*
+(and Trap Handler) responsibility. Callees (and Trap Handlers) **MUST**
+avoid using all and any SVP64 instructions during the period where state
+could be adversely affected. SVP64 purely relies on Scalar instructions,
+so Scalar instructions (except the SVP64 Management ones and mtspr and
+mfspr) are 100% guaranteed to have zero impact on SVP64 state.
+
+**SVme REMAP area**
+
+Each bit of `SVSTATE.SVme` indicates whether the SVSHAPE (0-3) is active and to which register
+the REMAP applies. The application goes by *assembler operand names* on a per-mnemonic
+basis. Some instructions may have `RT` as a source and as a destination: REMAP applies
+**separately** to each use in this case. Also for Load/Store with Update the Effective
+Address (stored in EA) also may be separately REMAPed from RA as a source operand.
+
+| bit|applies|register applied|
+|----|-------|----------------|
+| 46 | mi0 | source RA / FRA / BA / BFA / RT / FRT |
+| 45 | mi1 | source RB / FRB / BB|
+| 44 | mi2 | source RC / FRC / BC|
+| 43 | mo0 | result RT / FRT / BT / BF|
+| 42 | mo1 | result Effective Address (RA) / FRS / RS|
+
+**Max Vector Length (maxvl)** <a name="mvl" />
+
+MAXVECTORLENGTH is a static (immediate-operand only) compile-time declaration
+of the maximum number of elements in a Vector. MVL is limited to 7 bits
+(in the first version of SVP64) and consequently the maximum number of
+elements is limited to between 0 and 127.
+
+MAXVL is normally (in other True-Scalable Vector ISAs) an Architecturally-defined
+quantity related indirectly to the total available number of bits in the Vector
+Register File. Cray Vectors had a Hardware-Architectural set limit of MAXVL=64.
+RISC-V RVV has MAXVL defined in terms of a Silicon-Partner-selectable fixed number
+of bits. MAXVL in Simple-V is set in terms of the number of *elements* and
+may change at runtime.
+
+Programmer's Note: Except by directly using `mtspr` on SVSTATE, which may
+result in performance penalties on some hardware implementations, SVSTATE's `maxvl`
+field may only be set **statically** as an immediate, by the `setvl` instruction.
+It may **NOT** be set dynamically from a register. Compiler writers and assembly
+programmers are expected to perform static register file analysis, subdivision,
+and allocation and only utilise `setvl`. Direct writing to SVSTATE in order to
+"bypass" this Note could, in less-advanced implementations, potentially cause stalling,
+particularly if SVP64 instructions are issued directly after the `mtspr` to SVSTATE.
+
+**Vector Length (vl)** <a name="vl" />
+
+The actual Vector length, the number of elements in a "Vector", `SVSTATE.vl` may be set
+entirely dynamically at runtime from a number of sources. `setvl` is the primary
+instruction for setting Vector Length.
+`setvl` is conceptually similar but different from the Cray, SX Aurora, and RISC-V RVV
+equivalent. Similar to RVV, VL is set to be within
+the range 0 <= VL <= MVL. Unlike RVV, VL is set **exactly** according to the following:
+
+```
+ VL = (RT|0) = MIN(vlen, MVL)
+```
+
+where `0 <= MVL <= 127`, and vlen may come from an immediate, `RA`, or from the `CTR` SPR,
+depending on options selected with the `setvl` instruction.
+
+Programmer's Note: conceptual understanding of Cray-style Vectors is far beyond the scope
+of the Power ISA Technical Reference. Guidance on the 50-year-old Cray Vector paradigm is
+best sought elsewhere: good studies include Academic Courses given on the 1970s
+Cray Supercomputers over at least the past three decades.
+
+**Horizontal Parallelism**
+
+A problem exists for hardware where it may not be able to detect
+that a programmer (or compiler) knows of opportunities for parallelism
+and lack of overlap between loops, despite these being easy for a compiler
+to statically detect and potentially express.
+`hphint` is such an expression, declaring that elements within a batch are
+independent of each other (no Register *or Memory* Hazards).
+
+Elements are considered to be in the same source batch if they have
+the same value of `FLOOR(srcstep/hphint)`. Likewise in the same destination batch
+for the same value `FLOOR(dststep/hphint)`.
+Four key observations here:
+
+1. predication is **not** involved here. the number of actual elements
+involved is considered *before* predicate masks are applied.
+2. twin predication can result in srcstep and dststep being in different
+batches
+3. batch evaluation is done *before* REMAP, making Hazard elimination easier
+ for Multi-Issue systems.
+4. `hphint` is *not* limited to power-of-two. Hardware implementors may choose
+ a lower parallelism hint up to `hphint` and may find power-of-two more
+ convenient.
+
+Regarding (4): if a smaller hint is chosen by hardware, actual parallelism
+(Dependency Hazard relaxation) must **never**
+exceed `hphint` and must still respect the batch boundaries, even if this results
+in just one element being considered Hazard-independent. Even under these
+circumstances Multi-Issue Register-renaming is possible, to introduce parallelism
+by a different route.
+
+*Hardware Architect note: each element within the same group may be treated as
+100% independent from any other element within that group, and therefore
+neither Register Hazards nor Memory Hazards inter-element exist,
+but crucially inter-group definitely remains. This makes
+implementation far easier on resources because the Hazard Dependencies are
+effectively at a much coarser granularity than a single register.
+With element-width overrides extending down to the byte level reducing Dependency
+Hazard hardware complexity becomes even more important.*
+
+`hphint` may legitimately be set greater than `MAXVL`. This indicates to Multi-Issue
+hardware that even though MAXVL is relatively small the batches are *still independent*
+and therefore if Multi-Issue hardware chooses to allocate several batches up to
+`MAXVL` in size they are still independent, even if Register-renaming is deployed.
+This helps greatly simplify Multi-Issue systems by significantly reducing Hazards.
+
+**Considerable care** must be taken when setting `hphint`. Matrix Outer Product
+could produce corrupted results if `hphint` is set to greater than the innermost
+loop depth. Parallel Reduction, DCT and FFT REMAP all are similarly critically affected
+by `hphint` in ways that if used correctly greatly increases ease of parallelism but
+if done incorrectly will also result in data corruption. Reduction/Iteration
+also requires care to correctly declare in `hphint` how many elements are
+independent. In the case of most Reduction use-cases the answer is almost certainly
+"none".
+
+`hphint` must never be set on Atomic Memory operations, Cache-Inhibited
+Memory operations, or Load-Reservation Store-Conditional. Also if Load-with-Update
+Data-Dependent Fail-First is ever used for linked-list pointer-chasing, `hphint`
+should again definitely be disabled. Failure to do so results in `UNDEFINED`
+behaviour.
+
+`hphint` may only be ignored by Hardware Implementors as long as full element-level
+Register and Memory Hazards are implemented *in full* (including right down to individual
+bytes of each register for when elwidth=8/16/32). In other words if `hphint` is to
+be ignored then implementations must consider the situation as if `hphint=0`.
+
+**Horizontal Parallelism in Vertical-First Mode**
+
+Setting `hphint` with Vertical-First is perfectly legitimate. Under these circumstances
+single-element strict Program Execution Order must be preserved at all times, but
+should there be a small enough program loop, than Out-of-Order Hardware may
+take the opportunity to *merge*
+consecutive element-based instructions into the *same Reservation Stations*, for
+multiple operations to be passed to massive-wide back-end SIMD ALUs or Vector-Chaining ALUs.
+**Only** elements within the same `hphint` group (across multiple such looped instructions)
+may be treated as mergeable in this fashion.
+
+Note that if the loop of Vertical-First instructions cannot fit entirely into Reservation
+Stations then Hardware clearly cannot exploit the above optimisation opportunity, but at
+least there is no harm done: the loop is still correctly executed as Scalar instructions.
+Programmers do need to be aware though that short loops on some Hardware Implementations
+can be made considerably faster than on other Implementations.
+
+## SVLR
+
+SV Link Register, exactly analogous to LR (Link Register) may
+be used for temporary storage of SVSTATE, and, in particular,
+Vectorised Branch-Conditional instructions may interchange
+SVLR and SVSTATE whenever LR and NIA are.
+
+Note that there is no equivalent Link variant of SVREMAP or
+SVSHAPE0-3 (it would be too costly), so SVLR has limited applicability:
+REMAP SPRs must be saved and restored explicitly.
+
+-----------
+[[!tag standards]]
projects / libreriscv.git / blobdiff