(termed "preserving Program Order")
* Specifically designed to be Precise-Interruptible at all times
(many Vector ISAs have operations which, due to higher internal
- accuracy or other complexity, must be effectively atomic for
+ accuracy or other complexity, must be effectively atomic only for
the full Vector operation's duration, adversely affecting interrupt
response latency, or be abandoned and started again)
* Augments ("tags") existing instructions, providing Vectorisation
guaranteeing binary interoperability)
* Intel AVX-512 (and below): Hybrid Packed-Predicated SIMD with no
instruction-overloading, guaranteeing binary interoperability
- but penalising the ISA with uncontrolled opcode proliferation.
+ but at the same time penalising the ISA with runaway
+ opcode proliferation.
* ARM SVE/SVE2: Hybrid Packed-Predicated SIMD with instruction-overloading
that destroys binary interoperability. This is hidden behind the
- misuse of the word "Scalable".
+ misuse of the word "Scalable" and is **permitted under License**
+ by "Silicon Partners".
* RISC-V RVV: Cray-style Scalable Vector but with instruction-overloading
- that destroys binary interoperability.
+ **permitted by the specification** that destroys binary interoperability.
* SVP64: Cray-style Scalable Vector with no instruction-overloaded
meanings. The regfile numbers and bitwidths shall **not** change
in a future revision (for the same instruction encoding):
or are not immediately apparent despite the RISC paradigm
* [[opcode_regs_deduped]] autogenerated table of SVP64 decoder augmentation
* [[sv/sprs]] SPRs
+* [[sv/rfc]] RFCs to the [OPF ISA WG](https://openpower.foundation/isarfc/)
SVP64 "Modes":
Beyond this point are additional **Scalar** instructions related to
specific workloads that have nothing to do with the SV Specification*
+# Stability Guarantees in Simple-V
+
+Providing long-term stability in an ISA is extremely challenging
+but critically important.
+It requires certain guarantees to be provided.
+
+* Firstly: that instructions will never be ambiguously-defined.
+* Secondly, that no instruction shall change meaning to produce
+ different results on different hardware (present or future)
+* Thirdly, that implementors are not permitted to either add
+ arbitrary features nor implement features in an incompatible
+ way. *(Performance may differ, but differing results are
+ not permitted)*.
+* Fourthly, that any part of Simple-V not implemented by
+ a lower Compliancy Level is *required* to raise an illegal
+ instruction trap (allowing soft-emulation).
+* Fifthly, that any `UNDEFINED` behaviour for practical implementation
+ reasons is clearly documented for both programmers and hardware
+ implementors.
+
+In particular, given the strong recent emphasis and interest in
+"Scalable Vector" ISAs, it is most unfortunate that both ARM SVE
+and RISC-V RVV permit the exact same instruction to produce
+different results on different hardware depending on a
+"Silicon Partner" hardware choice. This choice catastrophically
+and irrevocably causes binary non-interoperability *despite being
+a "feature"*. Explained in <https://m.youtube.com/watch?v=HNEm8zmkjBU>
+
+It is therefore *guaranteed* that extensions to the register file
+width and quantity in Simple-V shall only be made in future by
+explicit means, ensuring binary compatibility.
+
+
# Optional Scalar instructions
**Additional Instructions for specific purposes (not SVP64)**
# Major opcodes summary <a name="major_op_summary"> </a>
-Simple-V itself only requires five instructions with 6-bit Minor XO
+Simple-V itself only requires six instructions with 6-bit Minor XO
(bits 26-31), and the SVP64 Prefix Encoding requires
25% space of the EXT001 Major Opcode.
There are **no** Vector Instructions and consequently **no further
is considerable concern that because there is not yet any two-way
day-to-day communication established with the OPF ISA WG, we have
no idea if any of these are conflicting with future plans by any OPF
-Members. **The External ISA WG RFC Process is yet to be ratified
-and Libre-SOC may not join the OPF as an entity because it does
+Members. **The External ISA WG RFC Process has now been ratified
+but Libre-SOC may not join the OPF as an entity because it does
not exist except in name. Even if it existed it would be a conflict
of interest to join the OPF, due to our funding remit from NLnet**.
We therefore proceed on the basis of making public the intention to
requiring two Major opcodes this would come to a grand total of 3 precious
Major opcodes. On balance, then, sacrificing 25% of EXT001 is the "least
difficult" choice.
+Alternative locations for SVP64
+Prefixing include EXT006 and EXT017, with EXT006 being most favourable
+as there is room for future expansion.
Note also that EXT022, the Official Architectural Sandbox area
available for "Custom non-approved purposes" according to the Power
ISA Spec,
is under severe design pressure as it is insufficient to hold
the full extent of the instruction additions required to create
-a Hybrid 3D CPU-VPU-GPU. Akthough the wording of the Power ISA
+a Hybrid 3D CPU-VPU-GPU. Although the wording of the Power ISA
Specification leaves open the *possibility* of not needing to
propose ISA Extensions to the ISA WG, it is clear that EXT022
is an inappropriate location for a large high-profile Extension
therefore be made to work with the OPF ISA WG to
submit SVP64 via the External RFC Process.
-**Whilst SVP64 is only 5 instructions
+**Whilst SVP64 is only 6 instructions
the heavy focus on VSX for the past 12 years has left the SFFS Level
anaemic and out-of-date compared to ARM and x86.**
This is very much
projects / libreriscv.git / blobdiff