but does **not** change the actual Decoding of that following instruction.
**All prefixed instructions retain their non-prefixed encoding and definition**.
-*Architectural Resource Allocation note: it is **prohibited** to accept RFCs which
+*Architectural Resource Allocation note: it is prohibited to accept RFCs which
fundamentally violate this hard requirement. Under no circumstances must the
Suffix space have an alternate instruction encoding allocated within SVP64 that is
entirely different from the non-prefixed Defined Word. Hardware Implementors
}
```
-Example add operation implementation when elwidths are 64-bit:
+Example Vector-looped add operation implementation when elwidths are 64-bit:
```
# add RT, RA,RB using the "uint64_t" union member, "l"
Hardware Architectural note: to avoid a Read-Modify-Write at the register file it is
strongly recommended to implement byte-level write-enable lines exactly as has been
implemented in DRAM ICs for many decades. Additionally the predicate mask bit is advised
-to be associated with the element operation and ultimately passed to the register file.
+to be associated with the element operation and alongside the result ultimately
+passed to the register file.
When element-width is set to 64-bit the relevant predicate mask bit may be repeated
eight times and pull all eight write-port byte-level lines HIGH. Clearly when element-width
is set to 8-bit the relevant predicate mask bit corresponds directly with one single
* SV Modes including saturation (for Audio, Video and DSP), mapreduce, fail-first and
predicate-result mode.
-Different classes of operations require
+Different classes of operations require different formats. The earlier sections cover
+the c9mmon formats and the four separate modes follow: CR operations (crops),
+Arithmetic/Logical (termed "normal"), Load/Store and Branch-Conditional.
-# Definition of Reserved in this spec.
+## Definition of Reserved in this spec.
For the new fields added in SVP64, instructions that have any of their
fields set to a reserved value must cause an illegal instruction trap,
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.
-# Definition of "UnVectoriseable"
+## Definition of "UnVectoriseable"
Any operation that inherently makes no sense if repeated is termed "UnVectoriseable"
or "UnVectorised". Examples include `sc` or `sync` which have no registers. `mtmsr` is
also classed as UnVectoriseable because there is only one `MSR`.
-# Scalar Identity Behaviour
+## Scalar Identity Behaviour
SVP64 is designed so that when the prefix is all zeros, and
VL=1, no effect or
Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops` (regardless of the prefix)
whereas when VL=1 and the SV prefix is all zeros, the operation simply acts as if SV had not been applied at all to the instruction (an "identity transformation").
-# Register Naming and size
+## Register Naming and size
-SV Registers are simply the INT, FP and CR register files extended
-linearly to larger sizes; SV Vectorisation iterates sequentially through these registers.
+As previously mentioned SV Registers are simply the INT, FP and CR register files extended
+linearly to larger sizes; SV Vectorisation iterates sequentially through these registers
+(LSB0 sequential ordering from 0 to VL-1).
Where the integer regfile in standard scalar
Power ISA v3.0B/v3.1B is r0 to r31, SV extends this as r0 to r127.
The mapping from the OpenPower v3.1 prefix bits to the Remapped Encoding
is defined in the Prefix Fields section.
-## Prefix Opcode Map (64-bit instruction encoding)
-
-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.
-
-| 6:11 | ---000 | ---001 | ---010 | ---011 | ---100 | ---101 | ---110 | ---111 |
-|------|--------|--------|--------|--------|--------|--------|--------|--------|
-|000---| 8LS | 8LS | 8LS | 8LS | 8LS | 8LS | 8LS | 8LS |
-|001---| | | | | | | | |
-|010---| 8RR | | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`|
-|011---| | | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`|
-|100---| MLS | MLS | MLS | MLS | MLS | MLS | MLS | MLS |
-|101---| | | | | | | | |
-|110---| MRR | | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`|
-|111---| | MMIRR | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`|
-
-Note that by taking up a block of 16, where in every case bits 7 and 9 are set, this allows svp64 to utilise four bits of the v3.1B Prefix space and "allocate" them to svp64's Remapped Encoding field, instead.
-
## Prefix Fields
+TODO incorporate EXT09
+
To "activate" svp64 (in a way that does not conflict with v3.1B 64 bit Prefix mode), fields within the v3.1B Prefix Opcode Map are set
(see Prefix Opcode Map, above), leaving 24 bits "free" for use by SV.
This is achieved by setting bits 7 and 9 to 1:
projects / libreriscv.git / commitdiff