-[[!tag standards]]
-
# Appendix
* <https://bugs.libre-soc.org/show_bug.cgi?id=574> Saturation
[[!toc]]
-# Partial Implementations
+## Partial Implementations
It is perfectly legal to implement subsets of SVP64 as long as illegal
instruction traps are always raised on unimplemented features,
See [[sv/compliancy_levels]] for full details.
-# XER, SO and other global flags
+## XER, SO and other global flags
Vector systems are expected to be high performance. This is achieved
through parallelism, which requires that elements in the vector be
1024-bit Add-with-Carry by setting VL=16, and so on. More on
this in [[openpower/sv/biginteger]]
-# EXTRA Field Mapping
+## EXTRA Field Mapping
The purpose of the 9-bit EXTRA field mapping is to mark individual
registers (RT, RA, BFA) as either scalar or vector, and to extend
be similar to deciding that `add` should be changed from X-Form
to D-Form.
-# Single Predication <a name="1p"> </a>
+#
# Single Predication <a name="1p"> </a>
This is a standard mode normally found in Vector ISAs. every element in every source Vector and in the destination uses the same bit of one single predicate mask.
Here, both srcstep and dststep remain in lockstep because sz=dz=1
-# Twin Predication <a name="2p"> </a>
+#
# Twin Predication <a name="2p"> </a>
This is a novel concept that allows predication to be applied to a single
source and a single dest register. The following types of traditional
is applied *in general* to Scalar operations, just like the x86
`REP` instruction (if put on steroids).
-# Pack/Unpack
+## Pack/Unpack
The pack/unpack concept of VSX `vpack` is abstracted out as Sub-Vector
reordering.
Pack/Unpack is enabled (set up) through [[sv/svstep]].
-# Reduce modes
+## Reduce modes
Reduction in SVP64 is deterministic and somewhat of a misnomer. A normal
Vector ISA would have explicit Reduce opcodes with defined characteristics
In essence it becomes the programmer's responsibility to leverage the
pre-determined schedules to desired effect.
-## Scalar result reduction and iteration
+### Scalar result reduction and iteration
Scalar Reduction per se does not exist, instead is implemented in SVP64
as a simple and natural relaxation of the usual restriction on the Vector
be precise.
-# Fail-on-first <a name="fail-first"> </a>
+#
# Fail-on-first <a name="fail-first"> </a>
Data-dependent fail-on-first has two distinct variants: one for LD/ST
(see [[sv/ldst]],
REMAP will need to be activated to invert the ordering of element
traversal.*
-## Data-dependent fail-first on CR operations (crand etc)
+### Data-dependent fail-first on CR operations (crand etc)
Operations that actually produce or alter CR Field as a result
do not also in turn have an Rc=1 mode. However it makes no
More details can be found in [[sv/cr_ops]].
-# pred-result mode
+## pred-result mode
Pred-result mode may not be applied on CR-based operations.
Arithmetic and Logical Pred-result, which does have Rc=1 or for which
RC1 Mode makes sense, is covered in [[sv/normal]]
-# CR Operations
+## CR Operations
CRs are slightly more involved than INT or FP registers due to the
possibility for indexing individual bits (crops BA/BB/BT). Again however
numbering, with a clear linear relationship and mapping existing when
SV is applied.
-## CR EXTRA mapping table and algorithm <a name="cr_extra"></a>
+##
# CR EXTRA mapping table and algorithm <a name="cr_extra"></a>
Numbering relationships for CR fields are already complex due to being
in BE format (*the relationship is not clearly explained in the v3.0B
simplify internal design. If instructions are issued where CR Vectors
do not start on a 32-bit aligned boundary, performance may be affected.
-## CR fields as inputs/outputs of vector operations
+### CR fields as inputs/outputs of vector operations
CRs (or, the arithmetic operations associated with them)
may be marked as Vectorised or Scalar. When Rc=1 in arithmetic operations that have no explicit EXTRA to cover the CR, the CR is Vectorised if the destination is Vectorised. Likewise if the destination is scalar then so is the CR.
(see [[discussion]]. some alternative schemes are described there)
-## Rc=1 when SUBVL!=1
+### Rc=1 when SUBVL!=1
sub-vectors are effectively a form of Packed SIMD (length 2 to 4). Only 1 bit of
predicate is allocated per subvector; likewise only one CR is allocated
OE is ignored in SVP64, this field may (when available) be used to select OR or
AND behavior.
-### Table of CR fields
+#### Table of CR fields
CRn is the notation used by the OpenPower spec to refer to CR field #i,
so FP instructions with Rc=1 write to CR1 (n=1).
which can be included in a table, which is in a new page (so as not to
overwhelm this one). [[svp64/cr_names]]
-# Register Profiles
+## Register Profiles
Instructions are broken down by Register Profiles as listed in the
following auto-generated page: [[opcode_regs_deduped]]. These tables,
despite being auto-generated, are part of the Specification.
-# SV pseudocode illustration
+## SV pseudocode illustration
-## Single-predicated Instruction
+### Single-predicated Instruction
illustration of normal mode add operation: zeroing not included, elwidth
overrides not included. if there is no predicate, it is set to all 1s
See <https://bugs.libre-soc.org/show_bug.cgi?id=552>
-# Assembly Annotation
+## Assembly Annotation
Assembly code annotation is required for SV to be able to successfully
mark instructions as "prefixed".
- mr OR crm: "normal" map-reduce mode or CR-mode.
- mr.svm OR crm.svm: when vec2/3/4 set, sub-vector mapreduce is enabled
-# Parallel-reduction algorithm
+## Parallel-reduction algorithm
The principle of SVP64 is that SVP64 is a fully-independent
Abstraction of hardware-looping in between issue and execute phases
if necessary or desired, to give the level of efficiency or performance
required.**
-# Element-width overrides <a name="elwidth"> </>
+#
# Element-width overrides <a name="elwidth"> </>
Element-width overrides are best illustrated with a packed structure
union in the c programming language. The following should be taken
element width, and the packing starts from the source (or destination)
specified by the instruction.
-# Twin (implicit) result operations
+## Twin (implicit) result operations
Some operations in the Power ISA already target two 64-bit scalar
registers: `lq` for example, and LD with update.
* [[isa/svfixedarith]]
* [[isa/svfparith]]
+[[!tag standards]]
+
+------
+
+\newpage()
+
projects / libreriscv.git / blobdiff