ls001 has been re-submitted, and already has questions being asked. actions: * 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. feedback required: * TODO comment #6 "presentation not consistent"
key primary addition: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=6eb3e78eb9e42947c76ed5cf140f6d151585bdd9
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 list) * 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.
https://ftp.libre-soc.org/opf_ext_rfc/ls001.v4.11apr2023.pdf re-submitted, v4, including the new PO9 Formal Request, as well as adding strncpy as it makes a great example. https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=bbb186ab1ab26cc0d36065521a82b5d53cfa607e
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=688b99a3cb97c5270e78103790813e78ed3fcce1 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 | + +Key: + +* **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 https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=2b82eb97d33a1687b0bbe5e8ccd483fb0fd6ad0b
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 > keywords. 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