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

[Luke Kenneth Casson Leighton]

On 10/27/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Tue, Oct 27, 2020, 14:24 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
>>
>> 1) "Notice how the WaR Waits on `r9` cause 2 instructions to finish
>> per cycle (5 micro-ops per 2 cycles)
>>
>> right.  this isn't necessarily the case.  once an FU has read from the
>> regfile into its in-flight it drops the dependency entirely.  thus if
>> the new instruction being issued is after that point there will only
>> be the one WaR wait, not two.
>>
>
> Those aren't caused by instructions needing to read the value (those are
> all taken care of by forwarding), but instead by the limit that each
> register can only write once per clock and because there is no mechanism to
> drop earlier writes when a later write is known to occur (and not be
> shadowed).

ok that's close enough a description of the WaW "stack" scenario i described.

yes we have a solution: i.e. we do in fact have a "mechanism" as you
call it to do exactly that (drop the earlier write).

this can only happen once all RaWs on that first r9 have occurred,
i.e. through Op-Fwd the value of (now completely nameless and
inflight-only) r9 is transferred from result FU to input latch RSes.

this is easily detected and trackable BUT it requires literally
doubling the FU-REGs cell size hence why i do not want it to be added
in the first iteration.

>>
>> 2) in column 3 i'm not seeing an INT reg write.  so the delay "Av r3"
>> is unnecessary.
>>
>
> That's caused by waiting for the associated memory read to finish before
> writing the ldu's address register, otherwise a sigsegv could cause the
> corruption of the register's previous value.

ah true but only until the LDST is detected as being clear of the LDST
hazard.  it would be perfectly reasonable to assume that the required
data is in the L1 cache, and that TLB lookup after AGEN gives the "ok"
straight away.

i.e. you don't have the LDST Addr Shadow held until the last minute.

wait... no, hang on, you've misunderstood Shadowing.  both the LDST
*and* all following instructions (all of them) are shadowed by the
LDST.

so whilst the AGEN (update of ldu) write cannot go ahead, OpFWDing
definitely can.

that's something that people miss: completed but non-committed
(shadowed) results can propagate to create a cascade of yet more
results, and, even, the one generated *after* the first could get
permission to write to the regfile before it did!  (because of
PriorityPickers not RoundRobin on GOWRITE selection).

l.