[Libre-soc-dev] WIP demo of deficiency of 6600-derived architecture compared to register renaming

[Luke Kenneth Casson Leighton]

ok so i think i identified the issue, it's a WaW Hazard
(write-after-write) which *external* renaming - nothing to do with
either Tomasulo or 6600 - would "solve".

i also mention how there does exist a 6600 augmentation "stack"
solution, it's just ridiculously expensive.

the WaW hazard exists between the ST (to r9) of one iteration and the
ADD (to r9) of the next.

i will be honest here and say up-front that i do not feel comfortable
trying to "fix" this in our first 6600 iteration either with the
solution that i came up with *or* with any other augmentation.  the
design is complex enough as it is without adding in what amount to
optimisations at a first iteration phase.

however in a *vector* context which matters to us much more than a
scalar one the fact that we have a "Cray Chaining" situation where the
VL loop does in fact give *real* register allocation that will in many
circumstances keep the issue engine so busy that it stays 100% full
and the WaW scenario does not occur.

there is however i think even a Vector Chaining situation where WaW
could occur, just inter-element.

fortunately it is not so hard to have the compiler just... not use
temporary registers in this way, avoiding the WaW hazard manually.

i am very much leaning for our first iteration (mid 2021?) to *not*
have to deal with WaW hazards initially, have the compilers simply
avoid it, and to leave hardware solutions until our second iteration.

l.