[Zero-Overhead Loop](https://en.m.wikipedia.org/wiki/Zero-overhead_looping)
Engine on top of
Scalar operations some clear guidelines are needed on how both
-existing "Defined Words" (Public v3.1 Section 1.6.3 term) and future
+existing "Defined Word-instructions" (Public v3.1 Section 1.6.3 term) and future
Scalar operations are added within the 64-bit space. Examples of
legal and illegal allocations are given later.
This is extremely important because the worst possible situation
is if a conflicting Scalar instruction is added by another Stakeholder,
which then turns out to be Vectorizeable: it would then have to be
-added to the Vector Space with a *completely different Defined Word*
+added to the Vector Space with a *completely different Defined Word-instruction*
and things go rapidly downhill in the Decode Phase from there.
Setting a simple inviolate rule helps avoid this scenario but does
need to be borne in mind when discussing potential allocation
* EXT009, like EXT001 of Public v3.1, is **defined** as a 64-bit
encoding. This makes Multi-Issue Length-identification trivial.
* bit 6 if 0b1 is 100% for Simple-V augmentation of (Public v3.1 1.6.3)
- "Defined Words" (aka EXT000-063), with the exception of 0x26000000
+ "Defined Word-instructions" (aka EXT000-063), with the exception of 0x26000000
as a Prefix, which is a new RESERVED encoding.
* when bit 6 is 0b0 and bits 32-33 are 0b11 are **defined** as also
allocated to Simple-V
which **must** be granted corresponding space
in SVP64.
* Anything Vectorized-EXT000-063 is **automatically** being
- requested as 100% Reserved for every single "Defined Word"
+ requested as 100% Reserved for every single "Defined Word-instruction"
(Public v3.1 1.6.3 definition). Vectorized-EXT001 or EXT009
is defined as illegal.
* Any **future** instruction
**EXT000-EXT063**
These are Scalar word-encodings. Often termed "v3.0 Scalar" in this document
-Power ISA v3.1 Section 1.6.3 Book I calls it a "defined word".
+Power ISA v3.1 Section 1.6.3 Book I calls it a "Defined Word-instruction".
| 0-5 | 6-31 |
|--------|--------|
-| PO | EXT000-063 "Defined word" |
+| PO | EXT000-063 "Defined Word-instruction" |
**SVP64Single:{EXT000-063}** bit6=old bit7=scalar
This encoding, identical to SVP64Single:{EXT248-263},
-introduces SVP64Single Augmentation of Scalar "defined words".
+introduces SVP64Single Augmentation of Scalar "Defined Word-instructions".
All meanings must be identical to EXT000-063, and is is likewise
prohibited to add an instruction in this area without also adding
the exact same (non-Augmented) instruction in EXT000-063 with the
the use of 0x12345678 for fredmv in scalar but fishmv in Vector is
illegal. the suffix in both 64-bit locations
must be allocated to a Vectorizeable EXT000-063
-"Defined Word" (Public v3.1 Section 1.6.3 definition)
+"Defined Word-instruction" (Public v3.1 Section 1.6.3 definition)
or not at all.
\newpage{}
| 64bit | sv.fishmv | 0x25nnnnnn | 0x12345678| vector SVP64:EXT2nn |
Both of these Simple-V operations are illegally-allocated. The fact that
-there does not exist a scalar "Defined Word" (even for EXT200-263) - the
+there does not exist a scalar "Defined Word-instruction" (even for EXT200-263) - the
unallocated block - means that the instruction may **not** be allocated in
the Simple-V space.
| 64bit | ss.fishmv | 0x24!zero | 0x10345678| scalar SVP64Single:EXT2nn |
| 64bit | sv.fishmv | 0x25nnnnnn | 0x10345678| vector SVP64:EXT2nn |
-This is an illegal attempt to place an EXT004 "Defined Word"
+This is an illegal attempt to place an EXT004 "Defined Word-instruction"
(Public v3.1 Section 1.6.3) into the EXT2nn Vector space.
This is not just illegal it is not even possible to achieve.
If attempted, by dropping EXT004 into bits 32-37, the top two
[^likeext001]: SVP64-Single is remarkably similar to the "bit 1" of EXT001 being set to indicate that the 64-bits is to be allocated in full to a new encoding, but in fact SVP64-single still embeds v3.0 Scalar operations.
[^pseudorewrite]: elwidth overrides does however mean that all SFS / SFFS pseudocode will need rewriting to be in terms of XLEN. This has the indirect side-effect of automatically making a 32-bit Scalar Power ISA Specification possible, as well as a future 128-bit one (Cross-reference: RISC-V RV32 and RV128
[^only2]: reminder that this proposal only needs 75% of two POs for Scalar instructions. The rest of EXT200-263 is for general use.
-[^ext001]: Recall that EXT100 to EXT163 is for Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which, from Section 1.6.3, bit 6 is set to 1. This concept is where the above scheme originated. Section 1.6.3 uses the term "defined word" to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed to create the new numbering EXT100-EXT163, respectively
+[^ext001]: Recall that EXT100 to EXT163 is for Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which, from Section 1.6.3, bit 6 is set to 1. This concept is where the above scheme originated. Section 1.6.3 uses the term "Defined Word-instruction" to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed to create the new numbering EXT100-EXT163, respectively
[^futurevsx]: A future version or other Stakeholder *may* wish to drop Simple-V onto VSX: this would be a separate RFC
[^vsx256]: imagine a hypothetical future VSX-256 using the exact same instructions as VSX. the binary incompatibility introducrd would catastrophically **and retroactively** damage existing IBM POWER8,9,10 hardware's reputation and that of Power ISA overall.
[^autovec]: Compiler auto-vectorization for best exploitation of SIMD and Vector ISAs on Scalar programming languages (c, c++) is an Indusstry-wide known-hard decades-long problem. Cross-reference the number of hand-optimised assembler algorithms.
projects / libreriscv.git / blobdiff