support, due to the high cost in both the ISA and in hardware. For
arbitrary remapping the `Indexed` REMAP may be used.
-# Usage
+# Executive Summary Usage
* `svshape` to set the type of reordering to be applied to the
usual `0..VL-1` hardware for-loop
The example may be executed as a unit test and demo,
[here](https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_matrix.py;h=c15479db9a36055166b6b023c7495f9ca3637333;hb=a17a252e474d5d5bf34026c25a19682e3f2015c3#l94)
-# Indexed REMAP
+# REMAP types
+
+This section summarises the motivation for each REMAP Schedule
+and briefly goes over their characteristics and limitations.
+
+## Matrix (1D/2D/3D shaping)
+
+TODO
+
+## FFT/DCT Triple Loop
+
+TODO
+
+## Indexed
The purpose of Indexing is to provide a generalised version of
Vector ISA "Permute" instructions, such as VSX `vperm`. The
extsw: there is no artificial limit.
The only major caveat is that the registers to be used as
-Indices must not be modified by any instruction during
-the time they are used.
+Indices must not be modified by any instruction after Indexed Mode
+is established, and neither must MAXVL be altered. Failure to observe
+these conditions results in `UNDEFINED` behaviour.
+These conditions allow a Read-After-Write (RAW) Hazard to be created on
+the entire range of Indices to be subsequently used, but a corresponding
+Write-After-Read Hazard by any instruction that modifies the Indices
+**does not have to be created**. Given the large number of registers
+involved in Indexing this is a huge resource saving and reduction
+in micro-architectural complexity. MAXVL is likewise
+included in the RAW Hazards because it is involved in calculating
+how many registers are to be considered Indices.
# REMAP SPR