From 967cfcb7905b6068a63791e1bea52b8f306da23f Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Thu, 3 Jan 2019 05:36:13 +0000 Subject: [PATCH] update predicate discussion --- updates/007_2018dec25_predication.mdwn | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) 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 -- 2.30.2