From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Thu, 3 Jan 2019 05:36:13 +0000 (+0000)
Subject: update predicate discussion
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=967cfcb7905b6068a63791e1bea52b8f306da23f;p=crowdsupply.git

update predicate discussion
---

diff --git a/updates/007_2018dec25_predication.mdwn b/updates/007_2018dec25_predication.mdwn
index 45a3047..8942af1 100644
--- 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