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

Jacob Lifshay programmerjake at gmail.com
Tue Oct 27 17:10:35 GMT 2020

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

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


More information about the Libre-soc-dev mailing list