(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 7f667c5bde837d215bdd8bb5662c0a649071332e..3085109f1285d1a961b85f3eee6f8e3976a00cf8 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -404,6 +404,28 @@ polar opposite, and in the end, the idea was thrown out, and Indexed
 REMAP added in its place.  Indexed REMAP comes with its own quirks,
 solving the Hazard problem, described in a later section.
 
+# REMAP and other reordering
+
+There are several places in Simple-V which apply some sort of reordering
+schedule to elements.  srcstep and dststep do not themselves reorder:
+they continue to march in sequence (VL-1 downto 0 in the case of reverse-gear)
+
+It is perfectly legal to apply Parallel-Reduction on top of any type
+of REMAP, for example, and it is possible to apply Pack/Unpack on a
+REMAP as well.
+
+The order of application of REMAP combined with Parallel-Reduction
+should be logically obvious: REMAP has to come first because otherwise
+how can the Parallel-Reduction perform a tree-walk?
+
+Pack/Unpack on the other hand is best implemented as applying first,
+because it is applied
+as the inversion of the for-loops which generate the steps and substeps.
+REMAP then applies to the src/dst-step indices (never to the subvl
+step indices: that is SWIZZLE's job).
+
+It's all perfectly logical, just a lot going on.
+
 # Branch-Conditional
 
 [[sv/branches]] are a very special exception to the rule that there