(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
Beyond this point are additional **Scalar** instructions related to
specific workloads that have nothing to do with the SV Specification*
-# Guarantees in Simple-V
+# Stability Guarantees in Simple-V
-Providing long-term stability in an ISA is extremely challenging.
+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.
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.
+ 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.
+ 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>
+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
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
projects / libreriscv.git / blobdiff