ls001 has been re-submitted, and already has questions being asked.
* TODO comment #6 use "Engineering Note" etc. and HEAI
* TODO comment #6 combine SV into one new big RFC (bug #NNNN)
* TODO comment #6 definitions in a new SV Chapter/Book, not main one.
* TODO comment #6 "from ground up" concepts.
* TODO comment #6 "presentation not consistent"
key primary addition:
1. we *want* the Decoder to be identical (because anything else is just nuts in hardware).
2. therefore i *thought* it was ok to request illegal instruction be raised on non-vectorised areas whereas
3. doing so makes the Decoder more complex and
4. if the UnVectoriseable instruction is repeated actually it just... gets repeated.
that said, it now occurs to me that there *is* actually an area (an opportunity) for raising the Illegal Instruction not as part of the "Defined Word" decoding, but as part of the "Mode Identification" Phase.
this phase is unavoidably necessary, and is required to provide the following additional information:
* what is the instruction's category? Arithmetic, LDST, CRops or Branch?
(this is exactly where "UnVectoriseable" may easily be added to the
* is it Twin or Single Predication
* How is the EXTRA2/3 area to be decoded? 1, 2, 3 or 4 regs?
* anything else (are 2 bits of EXTRA dedicated to SRC_ELWIDTH)
thi can be done *in parallel* with the Scalar "Defined Word" Decoding, and the results of these two phases passed to the SVP64 Augpmentation phase: creation of 7-bit GPR/FPR/CR-field numbers being the most important of these.
but this is a slight digression: the important fact answering your
question is that a category "No Category i.e. UnVectoriseable" can
easily be added and already has to be added because you need to stop
augmentation from happening. particularly in OoO high performance
systems you can early-exit from the Decoding (because the first
phase was sufficient and the second stage of Augmentation can be
bypassed) which any OoO Hardware Engineer will appreciate the
opportunity to reduce pipeline stage length.
overall then i think although i was on the wrong initial track
(wrong decoder) the principle of raising Illegal Instruction on
UnVectoriseable is sound, causing no latency, because the information
to do so is available and available early.
re-submitted, v4, including the new PO9 Formal Request, as well
as adding strncpy as it makes a great example.
the PO9 table needed a key, understanding its entries.
+| 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 |
+* **x** - a `RESERVED` encoding. Illegal Instruction Trap must be raised
+* **n** - a specification-defined value
+* **!zero** - a non-zero specification-defined value
+* **DWd** - "Defined Word" as explained in Book I Section 1.6 (Public v3.1 p11)
also clarify definitions
re-submitted *just* the PO9 part as a new Detailed RFC to the OPF
[[OPF][ISA] #197715] AutoReply: External Detailed RFC ls001.po9 v1: Allocation of 64-bit Primary Opcode 9
Comments from IBM architects regarding LS001 (PO9 allocation):
This is more of a proposal than an RFC. The main ideas seem pretty clear and plausible as extensions to the architecture, but there are details that aren’t well-explained.
* The presentation is not consistent with what would actually appear in the architecture document.
* No serious attempt is made to use documentation constructs in the existing architecture, e.g., Engineering Notes, or terminology, e.g., hypervisor emulation assistance interrupt.
* There are frequent references to other architectures instead of definitions constructed from the ground up as is done in the Power ISA.
* Some definitions seem more appropriate as names associated with facility descriptions in a new chapter about SimpleV than as standalone architecture keywords.
It seems likely that all of the RFCs that are pieces of SimpleV (not including new scalar instructions) should be combined into a single RFC because it doesn’t make sense to approve the component RFCs piecemeal.
(In reply to Paul Mackerras from comment #6)
> * Some definitions seem more appropriate as names associated with facility
> descriptions in a new chapter about SimpleV than as standalone architecture
my biggest concern about that is if instructions need to refer to
SV concepts. it can be done, just have to take care.
My comments on ls001.p09:
Regarding the definitions, it seems to me that definitions at this level of detail belong in the new Simple-V chapter rather than chapter 1.
The rest of the material seems to be about 70% admonishment to future architects and 30% information for present users and implementers. The 30% is useful, but in my opinion the 70% is not appropriate for the ISA, whose primary function is to define what the architecture currently is.
In particular, the use of terms like "prohibited" (concerning possible future modifications to the ISA) and the phrase "nor may they be revoked rescinded removed or recalled" are quite inappropriate for the ISA. If nothing else, they are a claim to having wisdom greater than any future architect will ever have, which is just presumptuous.
Another way to look at it is that the ISA is like a contract between programmers and implementers. It is quite inappropriate (not to mention ineffective) for a contract to try to say that the parties to the contract may not ever reach a different agreement between themselves.
feedback has been received on this bugreport, discussions have
taken place on the OPF ISA WG (Confidential). like bug #1179
this bugreport can nw be clsed and a new RFC for PO9 allocation
created, under a new bugreport #1180