update predicate discussion

diff --git a/updates/007_2018dec25_predication.mdwn b/updates/007_2018dec25_predication.mdwn
index 45a30479846912892d28927497f7e9bebe63afa5..8942af143bd67f266901906d2c44fb2a1f675f0a 100644 (file)
--- a/updates/007_2018dec25_predication.mdwn
+++ b/updates/007_2018dec25_predication.mdwn
@@ -22,12 +22,14 @@ 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.
+target.  That creates a write-hazard that has to be dealt with, as the
+predicated (Vectorised) instruction simply cannot be allowed to proceed
+until the instruction that is calculating its predicate has actually
+completed.  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.
+Let me repeat that again: the instruction issue phase that deals with
+predication **itself** has to have its own scoreboard Dependency Matrix entry.
 
 This brings some quite fascinating (read: scary) challenges and opportunities.
 If handled incorrectly, it means that the entire idea of using a multi-issue