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

[Jacob Lifshay]

On Tue, Oct 27, 2020, 09:56 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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.
>

your probably underestimating the additional compiler complexity...AFAIK
compilers generally assume that processors don't have performance penalties
for WaR or WaW hazards, so don't have code to avoid them.

>
> 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.
>

sounds good to me.

I am, however, going to finish the demo diagram since I think the issue is
a little more complex than just a WaW hazard.

Jacob