updates/007_2018dec25_predication.mdwn

   1 # Out-of-out-of-Order: Unpredictable Predication Predicament
   2
   3 So, early in the development of the Not-So-Simple-V specification it was
   4 identified that it meshed well with a multi-issue microarchitecture.
   5 Recall that the basic principle is that registers are "tagged" through
   6 a CSR table as "vectorised", and, if the Vector Length is greater than 1,
   7 *multiple* (sequential) instructions are issued to the pipeline (where
   8 one would normally be sent), *without* increasing the Program Counter,
   9 the difference between these otherwise identical instructions being that
  10 the source (and/or) destination registers are incremented continuously by
  11 one on each loop.
  12
  13 The nice thing about a multi-issue microarchitecture is that it is very
  14 simple to drop these element-based otherwise-identical instructions directly
  15 into the instruction FIFO.  What is even nicer is: when predication is
  16 introduced, all that needs to be done is that when the relevant element
  17 predicate bit is clear, the associated element-based instruction is
  18 **not** placed into the multi-issue instruction FIFO.
  19
  20 Simple, right?  Couldn't be easier.
  21
  22 The problem is: the predicate and the source and the destination registers
  23 can all come from the *same register file*.  So, one instruction may modify
  24 an integer register that on the *next instruction* is used as a predication
  25 target.  That creates a write-hazard that has to be dealt with.  That
  26 means that in this particular out-of-order architecture, the instruction
  27 issue phase itself has to become a Function Unit.
  28
  29 Let me repeat that again: the instruction issue phase *itself* has to
  30 have its own scoreboard Dependency Matrix entry.
  31
  32 This brings some quite fascinating (read: scary)