# SPRs <a name="sprs"></a>
-## SVSTATE SPR
+The full list of SPRs for Simple-V is:
+
+| 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 |
+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.
+
+## SVSTATE SPR
The format of the SVSTATE SPR is as follows:
| 40:41 | mo1 | REMAP EA/RS/FRS SVSHAPE0-3 |
| 42:46 | SVme | REMAP enable (RA-RT) |
| 47:52 | rsvd | reserved |
-| 53 | pack | PACK (srcstrp reorder) |
+| 53 | pack | PACK (srcstep reorder) |
| 54 | unpack | UNPACK (dststep order) |
| 55:61 | hphint | Horizontal Hint |
| 62 | RMpst | REMAP persistence |
* 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(srcstep/hphint)` is
- equal *before REMAP* are in the same parallelism "group". In Vertical First Mode
- hardware **MUST ONLY** process elements in the same group, and must stop
- Horizontal Issue at the last element of a given group. Set to zero to indicate "no hint".
+ (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 - when the corresponding SVme bit is enabled, these
+* 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: 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 save/restore the four SVSHAPE
+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*
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 the same concept as MVL in RISC-V RVV, except that it
-is variable length and may be dynamically set (normally from an immediate
-field only). MVL is limited to 7 bits
+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.
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,
+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
best sought elsewhere: good studies include Academic Courses given on the 1970s
Cray Supercomputers over at least the past three decades.
-**SUBVL - Sub Vector Length**
-
-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 main effect of SUBVL is that predication bits are applied per
-**group**, rather than by individual element. Legal values are 0 to 3,
-representing 1 operation (1 element) thru 4 operations (4 elements) respectively.
-Elements are best though of in the context of 3D, Audio and Video: two Left and Right
-Channel "elements" or four ARGB "elements", or three XYZ coordinate "elements".
-
-`subvl` is again primarily set by the `setvl` instruction. Not to be confused
-with `hphint`.
-
-Directly related to `subvl` is the `pack` and `unpack` Mode bits of `SVSTATE`.
-See `svstep` instruction for how to set Pack and Unpack Modes.
-
-
**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.
-
-For hphint, the number chosen must be consistently
-executed **every time**. Hardware is not permitted to execute five
-computations for one instruction then three on the next.
-hphint is a hint from the compiler to hardware that exactly this
-many elements may be safely executed in parallel, without hazards
-(including Memory accesses).
-Interestingly, when hphint is set equal to VL, it is in effect
-as if Vertical First mode were not set, because the hardware is
-given the option to run through all elements in an instruction.
-This is exactly what Horizontal-First is: a for-loop from 0 to VL-1
-except that the hardware may *choose* the number of elements.
-
-*Note to programmers: changing VL during the middle of such modes
-should be done only with due care and respect for the fact that SVSTATE
-has exactly the same peer-level status as a Program Counter.*
-
-*Hardare architectural note: each element within the same group may be treated as
+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. This makes
-implementation far easier on resources.*
+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
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