The fundamental principle of Simple-V is that it sits between Issue and
Decode, pausing the Program-Counter to service a "Sub-Program-Counter"
-hardware for-loop. In practical terms for many first-iteration
+hardware for-loop. In practical terms for many first-version
implementations this is sufficient.
**Considerable** effort has been expended to ensure that Simple-V is
practical to implement on an extremely wide range of Industry-wide
common **Scalar** micro-architectures. Finite State Machine (for
ultra-low-resource and Mission-Critical), In-order single-issue, all the
-way through to Great-Big Out-of-Order Superscalar Multi-Issue, and the
+way through to Great-Big Out-of-Order Superscalar Multi-Issue. The
SV Compliancy Levels specifically recognise these differing scenarios.
SIMD back-end ALUs particularly those with element-level predicate
masks may be exploited to good effect with very little additional
complexity to achieve high throughput, even on a single-issue in-order
-microarchitecture. As usually becomes apparent with in-order, its
+microarchitecture. As usually becomes quickly apparent with in-order, its
limitations extend also to when Simple-V is deployed, which is why
-Multi-Issue Out-of-Order is the recommended (but not mandatory)
+Multi-Issue Out-of-Order is the recommended (but not mandatory) Scalar
Micro-architecture.
The only major concern is in the upper SV Compliancy Levels: the Hazard
# Simple-V Architectural Resources
* No new Interrupt types are required.
- **No modifications to existing Power ISA are required either**.
+ (**No modifications to existing Power ISA are required either**).
* GPR FPR and CR Field Register numbers are extended to 128.
A future version may extend to 256 or beyond [^extend]
* (A future version or other Stakeholder *may* wish to drop Simple-V