-[[!tag standards]]
-
# Normal SVP64 Modes, for Arithmetic and Logical Operations
* <https://bugs.libre-soc.org/show_bug.cgi?id=574>
[[!toc]]
-# Mode
+## Mode
Mode is an augmentation of SV behaviour, providing additional
-functionality. Some of these alterations are element-based (saturation), others involve post-analysis (predicate result) and others are Vector-based (mapreduce, fail-on-first).
+functionality. Some of these alterations are element-based (saturation),
+others involve post-analysis (predicate result) and others are
+Vector-based (mapreduce, fail-on-first).
-[[sv/ldst]],
-[[sv/cr_ops]] and [[sv/branches]] are covered separately: the following
-Modes apply to Arithmetic and Logical SVP64 operations:
+[[sv/ldst]], [[sv/cr_ops]] and [[sv/branches]] are covered separately:
+the following Modes apply to Arithmetic and Logical SVP64 operations:
-* **simple** mode is straight vectorisation. no augmentations: the vector comprises an array of independently created results.
-* **ffirst** or data-dependent fail-on-first: see separate section. the vector may be truncated depending on certain criteria.
+* **simple** mode is straight vectorisation. no augmentations: the
+ vector comprises an array of independently created results.
+* **ffirst** or data-dependent fail-on-first: see separate section.
+ the vector may be truncated depending on certain criteria.
*VL is altered as a result*.
-* **sat mode** or saturation: clamps each element result to a min/max rather than overflows / wraps. allows signed and unsigned clamping for both INT
-and FP.
+* **sat mode** or saturation: clamps each element result to a min/max
+ rather than overflows / wraps. allows signed and unsigned clamping
+ for both INT and FP.
* **reduce mode**. if used correctly, a mapreduce (or a prefix sum)
is performed. see [[svp64/appendix]].
note that there are comprehensive caveats when using this mode.
-* **pred-result** will test the result (CR testing selects a bit of CR and inverts it, just like branch conditional testing) and if the test fails it
-is as if the
-*destination* predicate bit was zero even before starting the operation.
-When Rc=1 the CR element however is still stored in the CR regfile, even if the test failed. See appendix for details.
-
-Note that ffirst and reduce modes are not anticipated to be high-performance in some implementations. ffirst due to interactions with VL, and reduce due to it requiring additional operations to produce a result. simple, saturate and pred-result are however inter-element independent and may easily be parallelised to give high performance, regardless of the value of VL.
-
-The Mode table for Arithmetic and Logical operations
- is laid out as follows:
+* **pred-result** will test the result (CR testing selects a bit of CR
+ and inverts it, just like branch conditional testing) and if the
+ test fails it is as if the *destination* predicate bit was zero even
+ before starting the operation. When Rc=1 the CR element however is
+ still stored in the CR regfile, even if the test failed. See appendix
+ for details.
+
+Note that ffirst and reduce modes are not anticipated to be
+high-performance in some implementations. ffirst due to interactions
+with VL, and reduce due to it requiring additional operations to produce
+a result. simple, saturate and pred-result are however inter-element
+independent and may easily be parallelised to give high performance,
+regardless of the value of VL.
+
+The Mode table for Arithmetic and Logical operations is laid out as
+follows:
| 0-1 | 2 | 3 4 | description |
| --- | --- |---------|-------------------------- |
Fields:
-* **sz / dz** if predication is enabled will put zeros into the dest (or as src in the case of twin pred) when the predicate bit is zero. otherwise the element is ignored or skipped, depending on context.
+* **sz / dz** if predication is enabled will put zeros into the dest
+ (or as src in the case of twin pred) when the predicate bit is zero.
+ otherwise the element is ignored or skipped, depending on context.
* **zz**: both sz and dz are set equal to this flag
-* **inv CR bit** just as in branches (BO) these bits allow testing of a CR bit and whether it is set (inv=0) or unset (inv=1)
+* **inv CR bit** just as in branches (BO) these bits allow testing of
+ a CR bit and whether it is set (inv=0) or unset (inv=1)
* **RG** inverts the Vector Loop order (VL-1 downto 0) rather
-than the normal 0..VL-1
+ than the normal 0..VL-1
* **N** sets signed/unsigned saturation.
* **RC1** as if Rc=1, enables access to `VLi`.
* **VLi** VL inclusive: in fail-first mode, the truncation of
VL *includes* the current element at the failure point rather
than excludes it from the count.
-For LD/ST Modes, see [[sv/ldst]]. For Condition Registers
-see [[sv/cr_ops]].
-For Branch modes, see [[sv/branches]].
+For LD/ST Modes, see [[sv/ldst]]. For Condition Registers see
+[[sv/cr_ops]]. For Branch modes, see [[sv/branches]].
-# Rounding, clamp and saturate
+## Rounding, clamp and saturate
See [[av_opcodes]] for relevant opcodes and use-cases.
-To help ensure that audio quality is not compromised by overflow,
-"saturation" is provided, as well as a way to detect when saturation
-occurred if desired (Rc=1). When Rc=1 there will be a *vector* of CRs,
-one CR per element in the result (Note: this is different from VSX which
-has a single CR per block).
+To help ensure for example that audio quality is not compromised by
+overflow, "saturation" is provided, as well as a way to detect when
+saturation occurred if desired (Rc=1). When Rc=1 there will be a *vector*
+of CRs, one CR per element in the result (Note: this is different from
+VSX which has a single CR per block).
When N=0 the result is saturated to within the maximum range of an
unsigned value. For integer ops this will be 0 to 2^elwidth-1. Similar
or max of a signed result, and for FP to the min and max value rather
than returning +/- INF.
-When Rc=1, the CR "overflow" bit is set on the CR associated with the
-element, to indicate whether saturation occurred. Note that due to
-the hugely detrimental effect it has on parallel processing, XER.SO is
-**ignored** completely and is **not** brought into play here. The CR
-overflow bit is therefore simply set to zero if saturation did not occur,
-and to one if it did.
-
-Note also that saturate on operations that set OE=1 must raise an
-Illegal Instruction due to the conflicting use of the CR.so bit for
-storing if
-saturation occurred. Integer Operations that produce a Carry-Out (CA, CA32):
-these two bits will be `UNDEFINED` if saturation is also requested.
+When Rc=1, the CR "overflow" bit is set on the CR associated with
+the element, to indicate whether saturation occurred. Note that
+due to the hugely detrimental effect it has on parallel processing,
+XER.SO is **ignored** completely and is **not** brought into play here.
+The CR overflow bit is therefore simply set to zero if saturation did
+not occur, and to one if it did. This behaviour (ignoring XER.SO) is
+actually optional in the SFFS Compliancy Subset: for SVP64 it is made
+mandatory *but only on Vectorised instructions*.
+
+Note also that saturate on operations that set OE=1 must raise an Illegal
+Instruction due to the conflicting use of the CR.so bit for storing
+if saturation occurred. Vectorised Integer Operations that produce a
+Carry-Out (CA, CA32): these two bits will be `UNDEFINED` if saturation
+is also requested.
Note that the operation takes place at the maximum bitwidth (max of
src and dest elwidth) and that truncation occurs to the range of the
dest elwidth.
-*Programmer's Note: Post-analysis of the Vector of CRs to find out if any given element hit
-saturation may be done using a mapreduced CR op (cror), or by using the
-new crrweird instruction with Rc=1, which will transfer the required
-CR bits to a scalar integer and update CR0, which will allow testing
-the scalar integer for nonzero. see [[sv/cr_int_predication]]*
+*Programmer's Note: Post-analysis of the Vector of CRs to find out if any
+given element hit saturation may be done using a mapreduced CR op (cror),
+or by using the new crrweird instruction with Rc=1, which will transfer
+the required CR bits to a scalar integer and update CR0, which will allow
+testing the scalar integer for nonzero. see [[sv/cr_int_predication]].
+Alternatively, a Data-Dependent Fail-First may be used to truncate the
+Vector Length to non-saturated elements, greatly increasing the productivity
+of parallelised inner hot-loops.*
-# Reduce mode
+## Reduce mode
-Reduction in SVP64 is similar in essence to other Vector Processing
-ISAs, but leverages the underlying scalar Base v3.0B operations.
-Thus it is more a convention that the programmer may utilise to give
-the appearance and effect of a Horizontal Vector Reduction. Due
-to the unusual decoupling it is also possible to perform
-prefix-sum (Fibonacci Series) in certain circumstances. Details are in the [[svp64/appendix]]
+Reduction in SVP64 is similar in essence to other Vector Processing ISAs,
+but leverages the underlying scalar Base v3.0B operations. Thus it is
+more a convention that the programmer may utilise to give the appearance
+and effect of a Horizontal Vector Reduction. Due to the unusual decoupling
+it is also possible to perform prefix-sum (Fibonacci Series) in certain
+circumstances. Details are in the [[svp64/appendix]]
Reduce Mode should not be confused with Parallel Reduction [[sv/remap]].
As explained in the [[sv/appendix]] Reduce Mode switches off the check
which would normally stop looping if the result register is scalar.
-Thus, the result scalar register, if also used as a source scalar,
+Thus, the result scalar register, if also used as a source scalar,
may be used to perform sequential accumulation. This *deliberately*
-sets up a chain
-of Register Hazard Dependencies, whereas Parallel Reduce [[sv/remap]]
-deliberately issues a Tree-Schedule of operations that may be parallelised.
+sets up a chain of Register Hazard Dependencies, whereas Parallel Reduce
+[[sv/remap]] deliberately issues a Tree-Schedule of operations that may
+be parallelised.
-# Fail-on-first
+## Data-dependent Fail-on-first
-Data-dependent fail-on-first has two distinct variants: one for LD/ST,
-the other for arithmetic operations (actually, CR-driven). Note in each
-case the assumption is that vector elements are required to appear to be
-executed in sequential Program Order. When REMAP is not active,
+Data-dependent fail-on-first is CR-field-driven and is completely separate
+and distinct from LD/ST Fail-First (also known as Fault-First). Note in
+each case the assumption is that vector elements are required to appear
+to be executed in sequential Program Order. When REMAP is not active,
element 0 would be the first.
-Data-driven (CR-driven) fail-on-first activates when Rc=1 or other
+Data-driven (CR-field-driven) fail-on-first activates when Rc=1 or other
CR-creating operation produces a result (including cmp). Similar to
branch, an analysis of the CR is performed and if the test fails, the
vector operation terminates and discards all element operations **at and
-above the current one**, and VL is truncated to either
-the *previous* element or the current one, depending on whether
-VLi (VL "inclusive") is clear or set, respectively.
+above the current one**, and VL is truncated to either the *previous*
+element or the current one, depending on whether VLi (VL "inclusive")
+is clear or set, respectively.
-Thus the new VL comprises a contiguous vector of results,
-all of which pass the testing criteria (equal to zero, less than zero etc
-as defined by the CR-bit test).
+Thus the new VL comprises a contiguous vector of results, all of which
+pass the testing criteria (equal to zero, less than zero etc as defined
+by the CR-bit test).
*Note: when VLi is clear, the behaviour at first seems counter-intuitive.
A result is calculated but if the test fails it is prohibited from being
actually written. This becomes intuitive again when it is remembered
-that the length that VL is set to is the number of *written* elements,
-and only when VLI is set will the current element be included in that
-count.*
-
-The CR-based data-driven fail-on-first is "new" and not found in ARM
-SVE or RVV. At the same time it is "old" because it is almost
-identical to a generalised form of Z80's `CPIR` instruction.
-It is extremely useful for reducing instruction count,
-however requires speculative execution involving modifications of VL
-to get high performance implementations. An additional mode (RC1=1)
-effectively turns what would otherwise be an arithmetic operation
-into a type of `cmp`. The CR is stored (and the CR.eq bit tested
-against the `inv` field).
-If the CR.eq bit is equal to `inv` then the Vector is truncated and
-the loop ends.
+that the length that VL is set to is the number of *written* elements, and
+only when VLI is set will the current element be included in that count.*
+
+The CR-based data-driven fail-on-first is "new" and not found in ARM SVE
+or RVV. At the same time it is "old" because it is almost identical to
+a generalised form of Z80's `CPIR` instruction. It is extremely useful
+for reducing instruction count, however requires speculative execution
+involving modifications of VL to get high performance implementations.
+An additional mode (RC1=1) effectively turns what would otherwise be an
+arithmetic operation into a type of `cmp`. The CR is stored (and the
+CR.eq bit tested against the `inv` field). If the CR.eq bit is equal to
+`inv` then the Vector is truncated and the loop ends.
VLi is only available as an option when `Rc=0` (or for instructions
-which do not have Rc). When set, the current element is always
-also included in the count (the new length that VL will be set to).
-This may be useful in combination with "inv" to truncate the Vector
-to *exclude* elements that fail a test, or, in the case of implementations
-of strncpy, to include the terminating zero.
+which do not have Rc). When set, the current element is always also
+included in the count (the new length that VL will be set to). This may
+be useful in combination with "inv" to truncate the Vector to *exclude*
+elements that fail a test, or, in the case of implementations of strncpy,
+to include the terminating zero.
In CR-based data-driven fail-on-first there is only the option to select
and test one bit of each CR (just as with branch BO). For more complex
tests this may be insufficient. If that is the case, a vectorised crop
such as crand, cror or [[sv/cr_int_predication]] crweirder may be used,
-and ffirst applied to the crop instead of to
-the arithmetic vector. Note that crops are covered by
-the [[sv/cr_ops]] Mode format.
-
-*Programmer's note: `VLi` is only accessible in normal operations
-which in turn limits the CR field bit-testing to only `EQ/NE`.
-[[sv/cr_ops]] are not so limited. Thus it is possible to use for
-example `sv.cror/ff=gt/vli *0,*0,*0`, which is not a `nop` because
-it allows Fail-First Mode to perform a test and truncate VL.*
+and ffirst applied to the crop instead of to the arithmetic vector. Note
+that crops are covered by the [[sv/cr_ops]] Mode format.
+
+Use of Fail-on-first with Vertical-First Mode is not prohibited but is
+not really recommended. The effect of truncating VL
+may have unintended and unexpected consequences on subsequent instructions.
+VLi set will be fine: it is when VLi is clear that problems may be faced.
+
+*Programmer's note: `VLi` is only accessible in normal operations which in
+turn limits the CR field bit-testing to only `EQ/NE`. [[sv/cr_ops]] are
+not so limited. Thus it is possible to use for example `sv.cror/ff=gt/vli
+*0,*0,*0`, which is not a `nop` because it allows Fail-First Mode to
+perform a test and truncate VL.*
+
+*Hardware implementor's note: effective Sequential Program Order must
+be preserved. Speculative Execution is perfectly permitted as long as
+the speculative elements are held back from writing to register files
+(kept in Resevation Stations), until such time as the relevant CR Field
+bit(s) has been analysed. All Speculative elements sequentially beyond
+the test-failure point **MUST** be cancelled. This is no different from
+standard Out-of-Order Execution and the modification effort to efficiently
+support Data-Dependent Fail-First within a pre-existing Multi-Issue
+Out-of-Order Engine is anticipated to be minimal. In-Order systems on
+the other hand are expected, unavoidably, to be low-performance*.
Two extremely important aspects of ffirst are:
The second crucial aspect, compared to LDST Ffirst:
* LD/ST Failfirst may (beyond the initial first element
- conditions) truncate VL for any architecturally
- suitable reason. Beyond the first element LD/ST Failfirst is
- arbitrarily speculative and 100% non-deterministic.
+ conditions) truncate VL for any architecturally suitable reason. Beyond
+ the first element LD/ST Failfirst is arbitrarily speculative and 100%
+ non-deterministic.
* CR-based data-dependent first on the other hand MUST NOT truncate VL
arbitrarily to a length decided by the hardware: VL MUST only be
- truncated based explicitly on whether a test fails.
- This because it is a precise Deterministic test on which algorithms
- can and will will rely.
+ truncated based explicitly on whether a test fails. This because it is
+ a precise Deterministic test on which algorithms can and will will rely.
**Floating-point Exceptions**
When Floating-point exceptions are enabled VL must be truncated at
the point where the Exception appears not to have occurred. If `VLi`
-is set then VL must include the faulting element, and thus the
-faulting element will always raise its exception. If however `VLi`
-is clear then VL **excludes** the faulting element and thus the
-exception will **never** be raised.
+is set then VL must include the faulting element, and thus the faulting
+element will always raise its exception. If however `VLi` is clear then
+VL **excludes** the faulting element and thus the exception will **never**
+be raised.
-Although very strongly
-discouraged the Exception Mode that permits Floating Point Exception
-notification to arrive too late to unwind is permitted
-(under protest, due it violating
-the otherwise 100% Deterministic nature of Data-dependent Fail-first).
+Although very strongly discouraged the Exception Mode that permits
+Floating Point Exception notification to arrive too late to unwind
+is permitted (under protest, due it violating the otherwise 100%
+Deterministic nature of Data-dependent Fail-first).
**Use of lax FP Exception Notification Mode could result in parallel
computations proceeding with invalid results that have to be explicitly
detected, whereas with the strict FP Execption Mode enabled, FFirst
-truncates VL, allows subsequent parallel computation to avoid
-the exceptions entirely**
+truncates VL, allows subsequent parallel computation to avoid the
+exceptions entirely**
## Data-dependent fail-first on CR operations (crand etc)
-Operations that actually produce or alter CR Field as a result
-have their own SVP64 Mode, described
-in [[sv/cr_ops]].
+Operations that actually produce or alter CR Field as a result have
+their own SVP64 Mode, described in [[sv/cr_ops]].
-# pred-result mode
+## pred-result mode
This mode merges common CR testing with predication, saving on instruction
count. Below is the pseudocode excluding predicate zeroing and elwidth
-overrides. Note that the pseudocode for [[sv/cr_ops]] is slightly different.
+overrides. Note that the pseudocode for [[sv/cr_ops]] is slightly
+different.
+```
for i in range(VL):
# predication test, skip all masked out elements.
if predicate_masked_out(i):
continue
result = op(iregs[RA+i], iregs[RB+i])
CRnew = analyse(result) # calculates eq/lt/gt
- # Rc=1 always stores the CR
+ # Rc=1 always stores the CR field
if Rc=1 or RC1:
- crregs[offs+i] = CRnew
+ CR.field[offs+i] = CRnew
# now test CR, similar to branch
if RC1 or CRnew[BO[0:1]] != BO[2]:
continue # test failed: cancel store
# result optionally stored but CR always is
iregs[RT+i] = result
+```
The reason for allowing the CR element to be stored is so that
post-analysis of the CR Vector may be carried out. For example:
Note that predication is still respected: predicate zeroing is slightly
different: elements that fail the CR test *or* are masked out are zero'd.
+[[!tag standards]]
+
+--------
+
+\newpage{}
+
projects / libreriscv.git / commitdiff