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

[Jacob Lifshay]

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

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Tue, Oct 27, 2020 at 5:10 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > I think I found a performance deficiency where the 6600-derived
> > architecture has a bottleneck in the speed it can write to the
> > register file when one register is repeatedly written -- it's limited
> > to 1 write per clock, yet register renaming (since the writes are to
> > different registers due to renaming) can support more than 1 write per
> > clock cycle.
>
> ok: it is a common misconception that 6600-style architectures do not
> have register renaming: they have *nameless* registers because of the
> 1:1 correspondance between the CompUnit and its incoming (and outgoing
> in our case) register latches.
>

For the diagrams, I am assuming that there are an infinite number of ALUs
and FUs and register file R/W ports and timing is totally dependent on
dependencies between instructions, execution latencies, and fetch/decode
bandwidth (limited to 4 successive instructions per clock cycle). The issue
I'm trying to illustrate (but ran out of time to actually do so) is that
before instructions can complete (after execution and after any shadows are
released and sometimes after results are forwarded using the unspecified
method listed in my assumptions), they need to write their result latches
to the register file which is limited to 1 write per register per cycle
(otherwise you need additional write port priority logic, which quickly
becomes messy). Register renaming supports more than that, the illustrated
loop has 2 writes to r9 each loop and the steady state execution speed is 1
loop per cycle. I probably should have left out the loop startup sequence
to better illustrate my point.

I'll try to finish off the diagram today.

Jacob