add new update on predication

diff --git a/updates/007_2018dec25_predication.mdwn b/updates/007_2018dec25_predication.mdwn
new file mode 100644 (file)
index 0000000..ca0eb39
--- /dev/null
+++ b/updates/007_2018dec25_predication.mdwn
@@ -0,0 +1,32 @@
+# Out-of-out-of-Order: Unpredictable Predication Predicament
+
+So, early in the development of the Not-So-Simple-V specification it was
+identified that it meshed well with a multi-issue microarchitecture.
+Recall that the basic principle is that registers are "tagged" through
+a CSR table as "vectorised", and, if the Vector Length is greater than 1,
+*multiple* (sequential) instructions are issued to the pipeline (where
+one would normally be sent), *without* increasing the Program Counter,
+the difference between these otherwise identical instructions being that
+the source (and/or) destination registers are incremented continuously by
+one on each loop.
+
+The nice thing about a multi-issue microarchitecture is that it is very
+simple to drop these element-based otherwise-identical instructions directly
+into the instruction FIFO.  What is even nicer is: when predication is
+introduced, all that needs to be done is that when the relevant element
+predicate bit is clear, the associated element-based instruction is
+**not** placed into the multi-issue instruction FIFO.
+
+Simple, right?  Couldn't be easier.
+
+The problem is: the predicate and the source and the destination registers
+can all come from the *same register file*.  So, one instruction may modify
+an integer register that on the *next instruction* is used as a predication
+target.  That creates a write-hazard that has to be dealt with.  That
+means that in this particular out-of-order architecture, the instruction
+issue phase itself has to become a Function Unit.
+
+Let me repeat that again: the instruction issue phase *itself* has to
+have its own scoreboard Dependency Matrix entry.
+
+This brings some quite fascinating (read: scary)