Simple-V operates on an entirely different paradigm from traditional
Vector ISAs: as a Sub-Program Counter where "Elements" are synonymous
with Scalar instructions. With this in mind it is critical for
-implementations to observe Strict Element-Level Program Order.
+implementations to observe Strict Element-Level Program Order
+at all times. *Any* element is Interruptible and Simple-V has
+been carefully designed to ensure that Architectural State is
+fully preserved.
+
Interrupts still only save `MSR` and `PC` in `SRR0` and `SRR1`
but the full SVP64 Architectural State may be saved and
restored through manual copying of `SVSTATE` and the four
-REMAP SPRs.
+REMAP SPRs. Whilst this initially sounds unsafe in reality
+all rhat Trap Handlers (and function call stack save/restore)
+need do is avoid
+use of SVP64 Prefixed instructions to perform the necessary
+save/restore of Simple-V Architectural State.
This capability also allows nested function calls to be made from
-inside Vector loops, which is unusual for Vector ISAs.
+inside Vector loops, which is very rare for Vector ISAs.
Strict Program Order is also preserved by the Parallel Reduction
REMAP Schedule, but only at the cost of requiring the destination
-Vector to be permitted to store partial progress of the Deterministic
+Vector to be used (Deterministically) to store partial progress of the
Parallel Reduction Schedule.
+The only major caveat for REMAP is that
+after an explicit change to
+Architectural State caused by writing to the
+Simple-V SPRs, some implementations may find
+it easier to take longer to calculate where in a given Schedule
+the re-mapping Indices were. Obvious examples include Interrupts occuring
+in the middle of a non-RADIX2 Matrix Multiply Schedule (5x3 by 3x3
+for example), which
+will force implementations to perform divide and modulo
+calculations.
+
## SVP64 encoding features
A number of features need to be compacted into a very small space of
projects / libreriscv.git / commitdiff