# 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)