**Definition of Simple-V:**
-In its simpest form, the Simple-V Loop/Vector concept is a Prefixing
-system (sililar to the 8086 `REP` instruction) that both augments its
+In its simplest form, the Simple-V Loop/Vector concept is a Prefixing
+system (similar to the 8086 `REP` instruction) that both augments its
following Defined Word Suffix, and also may repeat that instruction
with optional sequential register offsets from those given in the
Suffix. Register numbers may also be extended (larger register files).
**Definition of SVP64 Prefixing:**
SVP64 is a well-defined implementation of the Simple-V Loop/Vector concept,
-in a 32-bit Prefix format, that exploits the following instruction
+in a 32-bit Prefix format, that exploits the following instruction
(the Defined Word) using it as a "template". It requires 24 bits,
some of which are common to all Suffixes, and some Mode bits are specific
to the Defined Word class: Load/Store-Immediate, Load/Store-Indexed,
Arithmetic/Logical, Condition Register operations, and Branch-Conditional.
Anything not falling into those five categories is termed "UnVectoriseable".
-**Definition of Vertical-First:**
+**Definition of Horizontal-First:**
Normal Cray-style Vectorisation, designated Horizontal-First, performs
element-level operations (often in parallel) before moving in the usual
-fashion to the next instruction. Vertical-First on the other hand executes
+fashion to the next instruction. The term "Horizontal-First"
+stems from visually listing program instructions vertically and register
+files horizontally, whereupon it is clear that register-elements are
+prioritised.
+
+**Definition of Vertical-First:**
+
+Vertical-First executes
*one element operation only* then moves on to the next instruction,
whereupon if that is also an SVP64-Prefixed instruction the exact same
element offset is used. Element offsets are then explicitly advanced
by calling a special instruction, `svstep`. The term "Vertical-First"
stems from visually listing program instructions vertically and register
-files horizontally.
+files horizontally, where moving to the next instruction is a clear priority.
**Definition of SVP64Single Prefixing:**
A 32-bit Prefix in front of a Defined Word that extends register
numbers (allows larger register files), adds single-bit predication,
element-width overrides, and optionally adds Saturation to Arithmetic
-instructions that normally would not have it. *SVP64 is in Draft only*
+instructions that normally would not have it. *SVP64Single is in Draft only*
and is yet to be defined.
**Definition of "UnVectoriseable":**
UnVectorised instructions are required to be detected as such if Prefixed
(either SVP64 or SVP64Single) and an Illegal Instruction Trap raised.
-*Architectural Note: Given that a "pre-classification" Decode Phase
+*Hardware Architectural Note: Given that a "pre-classification" Decode Phase
is required (identifying whether the Suffix - Defined Word - is
Arithmetic/Logical, CR-op, Load/Store or Branch-Conditional), adding
"UnVectorised" to this phase is not unreasonable.*
as a new 64-bit encoding space, alongside Primary Opcode 1
(EXT1xx).
-| 0-5 | 6 | 7 | 8-31 | 32| Description |
-|-----|---|---|-------|---|------------------------------------|
-| PO | 0 | x | xxxx | 0 | `RESERVED2` (57-bit) |
-| PO | 0 | 0 | !zero | 1 | SVP64Single:EXT232-263, or `RESERVED3` |
-| PO | 0 | 0 | 0000 | 1 | Scalar EXT232-263 |
-| PO | 0 | 1 | nnnn | 1 | SVP64:EXT232-263 |
-| PO | 1 | 0 | 0000 | x | `RESERVED1` (32-bit) |
-| PO | 1 | 0 | !zero | n | SVP64Single:EXT000-063 or `RESERVED4` |
-| PO | 1 | 1 | nnnn | n | SVP64:EXT000-063 |
+| 0-5 | 6 | 7 | 8-31 | 32|33-63|Description |
+|-----|---|---|-------|---|-----|-----------------------------------|
+| PO9 | 0 | x | xxxx | 0 | xxxx| `RESERVED2` (57-bit) |
+| PO9 | 0 | 0 | !zero | 1 | DWd | SVP64Single:EXT232-263, or `RESERVED3` |
+| PO9 | 0 | 0 | 0000 | 1 | DWd | Scalar EXT232-263 |
+| PO9 | 0 | 1 | nnnn | 1 | DWd | SVP64:EXT232-263 |
+| PO9 | 1 | 0 | 0000 | x | xxxx| `RESERVED1` (32-bit) |
+| PO9 | 1 | 0 | !zero | n | DWd | SVP64Single:EXT000-063 or `RESERVED4` |
+| PO9 | 1 | 1 | nnnn | n | DWd | SVP64:EXT000-063 |
+
+Key:
+
+* **x** - a `RESERVED` encoding. Illegal Instruction Trap must be raised
+* **n** - a specification-defined value
+* **!zero** - a non-zero specification-defined value
+* **DWd** - when including bit 32 is a "Defined Word" as explained in
+ Book I Section 1.6 (Public v3.1 p11)
Note that for the future SVP64Single Encoding (currently RESERVED3 and 4)
it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
prohibition allows SVP64Single to share its Encoding space with Scalar
-Ext232-263 and Scalar EXT300-363.
+EXT232-263 and Scalar EXT300-363.
Also that RESERVED1 and 2 are candidates for future Major opcode
areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
an independent 32-bit Defined Word. The only semi-exceptions are
the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.*
+Note a special application of the above paragraph: due to the fact that
+the Prefix Encodings are independent, **by definition** two new Sandbox
+areas "come into being" in an **inviolate** manner (i.e. they may not
+be called anything else, nor may they be revoked rescinded removed or
+recalled), named `SVP64:EXT022` and `SVP64Single:EXT022`. The **only
+way** that these two new areas may be revoked is if EXT022 itself
+is revoked. **All and any** re-definitions modifications enhancements
+clarifications that apply to EXT022 **also apply to these two new areas**
+because due to the Prefixes being independent Defined Words the three
+areas are actually one and the same area.
+
Encoding spaces and their potential are illustrated:
| Encoding |Available bits|Scalar|Vectoriseable | SVP64Single |PO1-Prefixable |
Notes:
-* Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
+* **PO9**-PO1 Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
on top of an SVP64 prefix which is 32-bit on top of a Defined Word
and the complexity at the Decoder becomes too great for High
Performance Multi-Issue systems.
+* There is however no reason why PO9-PO1 (EXT901?) as an entirely new RESERVED
+ 64-bit Encoding
+ should not be permitted as long as it is clearly marked as UnVectoriseable.
+* PO1-**PO9** Prefixed-Prefixed (96-bit) instructions are also prohibited
+ for the same reason: Multi-Issue Decode complexity is too great.
+* There is however no reason why PO1-PO9 (EXT109) as an entirely new RESERVED
+ 64-bit Encoding
+ should not be permitted as long as it is clearly marked as UnVectoriseable.
* EXT100-163 instructions (PO1-Prefixed) are also prohibited from being
double-PO1-prefixed (not twice prefixed)
* RESERVED2 presently remains unallocated as of yet and therefore its
that the area is UnVectoriseable and also cannot be Prefixed with
SVP64Single.
* Considerable care is needed both on Architectural Resource Allocation
- as well as instruction design itself. Once an instruction is allocated
+ as well as instruction design itself. All new Scalar instructions automatically
+ and inherently must be designed taking their Vectoriseable potential into
+ consideration *including VSX* in future.
+* Once an instruction is allocated
in an UnVectoriseable area it can never be Vectorised without providing
an entirely new Encoding.
projects / libreriscv.git / blobdiff