[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

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.libre-soc.org/
                   |                            |show_bug.cgi?id=352,
                   |                            |https://bugs.libre-soc.org/
                   |                            |show_bug.cgi?id=737
                 CC|                            |lkcl at lkcl.net
                URL|                            |https://libre-soc.org/3d_gp
                   |                            |u/isa_to_virtual_regs/

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
two parts:

part 1
------

the architectural design for register renaming is already done, following
a discussion last year with Mitch Alsup on comp.arch.  this is the
table for the port management:

https://libre-soc.org/3d_gpu/isa_to_virtual_regs/

requests for access to a read/write a register file port come in on the columns
(bottom), and go out on the rows (left).

also required for Write-after-Write (which is basically what register
renaming is) is a pair of FU-Regs and FU-FU Matrices, adapted to work
"in reverse" (see comp.arch discussion at the url), names "FU" replaced
with "VirtualReg" and "Regs" replaced with "Physical" i.e. the Matrices
become named "VirtualReg-PhysicalReg" and "VirtualReg-VirtualReg".

the matrices are not quite exactly the same as FU-Regs and FU-FU: the
driving force (decision logic) goes in the *opposite* direction.
i don't recall the exact details of the comp.arch discussion,
it was 14 months ago.  looks like this was it:

https://groups.google.com/g/comp.arch/c/vdgvrYGoxTM/m/w8jAF56fBgAJ

ah, it was the Shadowing.  the Shadowing operates in the opposite
direction.

part 2
------

you *may* be referring to reducing the size of the FU-Regs Matrices.
a technique there is instead of one FU-Regs column per register,
to map multiple registers down to one column.

the most ridiculous but perfectly legitimate version of that is to
map *all* registers down to a single hazard bit per read and per
write port.

for the SPR regfile this may be directly necessary *right now*
because there are over 100 entries and it is flat-out completely
impractical to have a 100-wide SPR regfile hazard bitvector.

the upshot of such a type of drastic decision is that *only one
instruction at a time may be in-flight* which wishes to write to
the entire SPR regfile, and in a simple design in the case of writing
to the SPR regfile that may be exactly what is needed.

less draconian decisions can also be made by allowing certain
SPRs to have their own dedicated Hazard column such as for the
Galois Field instruction for setting the modulo.

this is already partly done in the form of splitting up the XER
SPR which has a very special 3-entry 2-bit regfile (SO, CA, OV
where the top - 2nd - bit of SO is ignored) and consequently
it has its own 3-wide Hazard Protection.

bottom line is that you do not have to think of the mapping of
hazard protection to be *exactly* one-to-one and onto registers:
FU-Regs protects *contended resources*.  defining what those
"contended resources" are is entirely up to you.

part 3
------

combining those two: i believe what you are saying is that you are
thinking in terms of a dedicated FU (or, more accurately, dedicated
Reservation Station) per "Virtually-Allocated-Register".  in other
words, in OoO Tomasulo terminology, it would be the "Reorder Buffer Row"
(ROB) or ROB in-flight row number.

this is definitely WaW and definitely requires a FU-Regs + FU-FU
pair (renamed to VirtRegs-RealRegs Virt-Virt or better
ROBInFlightRow-RealRegs ROBInFlightRow-ROBInFlightRow)

or, if either single-issue or absolute hell-on-earth multi-ported
lookup or severe limitations on the routing are tolerable, a CAM.

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