[Libre-soc-bugs] [Bug 751] idea for reducing dependency matrixes in 6600-derived architecture with register renaming

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=751

--- Comment #3 from Jacob Lifshay <programmerjake at gmail.com> ---
This idea is intended for a cpu where all micro-ops only write to one register
each...it can be extended by having multiple output registers per FU (assumes
all outputs are written simultaneously) -- equivalent to one wide output
register with fields for several ISA-level registers' values -- e.g. add. would
have an output field for RT and for CR0.

The idea uses a mostly traditional register renaming scheme where ISA-level
registers are renamed into "physical registers" or "hardware registers"
(traditional names -- these are associated 1:1 with FUs' output registers in
this idea) as a pipeline stage in the fetch-decode pipe immediately after
decode and immediately before dispatching instructions to FUs.

For an example of what I mean by traditional register renaming, see:
https://ftp.libre-soc.org/power-cpu-sim/
(requires javascript and a modern browser)
but mentally add a dispatch stage after renaming.
Code:
https://salsa.debian.org/Kazan-team/power-cpu-sim/-/tree/10b113faab52890dd77809096d5a664ece6b069e

For cases such as:
add r0, ...
add r1, ...
add r2, ...
...
add r31, ...
where you likely need more physical registers than the number of FUs for any
one ALU:
we could add a separate ALU that just copies the input value into cold-storage
(aka. a move-only ALU) -- this'd be the only ALU that breaks the 1 FU 1
physical register rule -- it would have enough registers for all ISA-level
registers to fit but only a few FUs. the register rename stage would insert
copy ops before reallocating a physical register/FU (belonging to a normal ALU
pipe) if it was still used by any ISA-level registers -- the rename stage would
stall until both nothing was reading the FU to be reallocated's output and
until the FU computed its output (stall happens anyway when all FUs for an ALU
are still computing).

-- 
You are receiving this mail because:
You are on the CC list for the bug.