[[!tag standards]]
-# DRAFT SVP64 for OpenPOWER ISA v3.0B
+# DRAFT SVP64 for Power ISA v3.0B
* **DRAFT STATUS v0.1 18sep2021** Release notes <https://bugs.libre-soc.org/show_bug.cgi?id=699>
-This document describes [[SV|sv]] augmentation of the [[OpenPOWER|openpower]] v3.0B [[ISA|openpower/isa/]]. It is in Draft Status and
+This document describes [[SV|sv]] augmentation of the [[Power|openpower]] v3.0B [[ISA|openpower/isa/]]. It is in Draft Status and
will be submitted to the [[!wikipedia OpenPOWER_Foundation]] ISA WG
via the External RFC Process.
in order to allow emulation.
Unless otherwise stated, reserved values are always all zeros.
-This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero. Where the standard OpenPOWER definition
+This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero. Where the standard Power ISA definition
is intended the red keyword `RESERVED` is used.
# Scalar Identity Behaviour
SVP64 is designed so that when the prefix is all zeros, and
VL=1, no effect or
-influence occurs (no augmentation) such that all standard OpenPOWER
+influence occurs (no augmentation) such that all standard Power ISA
v3.0/v3 1 instructions covered by the prefix are "unaltered". This is termed `scalar identity behaviour` (based on the mathematical definition for "identity", as in, "identity matrix" or better "identity transformation").
Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops` (regardless of the prefix)
linearly to larger sizes; SV Vectorisation iterates sequentially through these registers.
Where the integer regfile in standard scalar
-OpenPOWER v3.0B/v3.1B is r0 to r31, SV extends this as r0 to r127.
+Power ISA v3.0B/v3.1B is r0 to r31, SV extends this as r0 to r127.
Likewise FP registers are extended to 128 (fp0 to fp127), and CR Fields
are
extended to 128 entries, CR0 thru CR127.
The names of the registers therefore reflects a simple linear extension
-of the OpenPOWER v3.0B / v3.1B register naming, and in hardware this
+of the Power ISA v3.0B / v3.1B register naming, and in hardware this
would be reflected by a linear increase in the size of the underlying
SRAM used for the regfiles.
## Prefix Opcode Map (64-bit instruction encoding)
-In the original table in the v3.1B OpenPOWER ISA Spec on p1350, Table 12, prefix bits 6:11 are shown, with their allocations to different v3.1B pregix "modes".
+In the original table in the v3.1B Power ISA Spec on p1350, Table 12, prefix bits 6:11 are shown, with their allocations to different v3.1B pregix "modes".
The table below hows both PowerISA v3.1 instructions as well as new SVP instructions fit;
empty spaces are yet-to-be-allocated Illegal Instructions.
* MASK (and MASK_SRC) and MASKMODE provide predication (two types of sources: scalar INT and Vector CR).
* Bits 10 to 18 (EXTRA) are further decoded depending on the RM category for the instruction, which is determined only by decoding the Scalar 32 bit suffix.
-Similar to OpenPOWER `X-Form` etc. EXTRA bits are given designations, such as `RM-1P-3S1D` which indicates for this example that the operation is to be single-predicated and that there are 3 source operand EXTRA tags and one destination operand tag.
+Similar to Power ISA `X-Form` etc. EXTRA bits are given designations, such as `RM-1P-3S1D` which indicates for this example that the operation is to be single-predicated and that there are 3 source operand EXTRA tags and one destination operand tag.
Note that if ELWIDTH != ELWIDTH_SRC this may result in reduced performance or increased latency in some implementations due to lane-crossing.
it is up to the programmer to ensure that the CR fields used as
Predicate Masks are not being written to by any parallel Vector Loop.
Doing so results in **UNDEFINED** behaviour, according to the definition
-outlined in the OpenPOWER v3.0B Specification.
+outlined in the Power ISA v3.0B Specification.
Hardware Implementations are therefore free and clear to delay reading
of individual CR fields until the actual predicated element operation
# Extra Remapped Encoding <a name="extra_remap"> </a>
-Shows all instruction-specific fields in the Remapped Encoding `RM[10:18]` for all instruction variants. Note that due to the very tight space, the encoding mode is *not* included in the prefix itself. The mode is "applied", similar to OpenPOWER "Forms" (X-Form, D-Form) on a per-instruction basis, and, like "Forms" are given a designation (below) of the form `RM-nP-nSnD`. The full list of which instructions use which remaps is here [[opcode_regs_deduped]]. (*Machine-readable CSV files have been provided which will make the task of creating SV-aware ISA decoders easier*).
+Shows all instruction-specific fields in the Remapped Encoding `RM[10:18]` for all instruction variants. Note that due to the very tight space, the encoding mode is *not* included in the prefix itself. The mode is "applied", similar to Power ISA "Forms" (X-Form, D-Form) on a per-instruction basis, and, like "Forms" are given a designation (below) of the form `RM-nP-nSnD`. The full list of which instructions use which remaps is here [[opcode_regs_deduped]]. (*Machine-readable CSV files have been provided which will make the task of creating SV-aware ISA decoders easier*).
These mappings are part of the SVP64 Specification in exactly the same
way as X-Form, D-Form. New Scalar instructions added to the Power ISA
## INT/FP EXTRA3
If EXTRA3 is zero, maps to
-"scalar identity" (scalar OpenPOWER ISA field naming).
+"scalar identity" (scalar Power ISA field naming).
Fields are as follows:
## INT/FP EXTRA2
If EXTRA2 is zero will map to
-"scalar identity behaviour" i.e Scalar OpenPOWER register naming:
+"scalar identity behaviour" i.e Scalar Power ISA register naming:
| Value | Mode | Range/inc | 6..0 |
|-----------|-------|---------------|-----------|
projects / libreriscv.git / commitdiff