[Libre-soc-bugs] [Bug 352] virtual (dependency-tracked) regfile (cache) needed

[bugzilla-daemon at libre-soc.org]

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

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
the scope here, the number and type of regfiles, is going to be quite large.

* 128 64-bit INTs
* 128 64-bit FPs
* 8 (64? 128?) 4-bit CRs
* 8 "FAST" SPRs (TAR, CTR etc)

these are the major ones: XER is only 3 regs, SPRs, and even potentially the
FAST regs (TAR, CTR, LR, SRR1/0) do not really need to be virtualised.  SPRs
(except FAST ones) are uncommon and do not interact with other regfiles in ways
that need virtualisation.

a case could be made however to virtualise (and rename) the FAST regs given how
jacob showed that CTR is for example critical to loops (bcctr).

the number of INTs and FPs alone leaves us with an enormous register address
space: *9* bits!  most architectures only use 5!

CRs being only 4 bit could be considered separate and given their own cache. 
however INT and FP and probably FAST seem like they should all be in the same
cache/renaming, particularly as they are all 64 bit.


on the other side of the equation is the number of virtual regs, which will
define (match exactly) the column width of the FU-REGs DM.  32 may be too small
(run out), 64 is getting to the point where the size of the FU-REGs DM is a
little large.

note that even the original 6600 had 24 registers (A, B, X) although it was a
sparse FU-REGs matrix because not all opcodes used all 3 regtypes.


so this defines the scope:

* 9 bit addressing of physical regs
* 6 bit addressing of virtual regs

this is however *without* register renaming which effectively introduces a
minimum of 1 extra bit and potentially as high as 5 extra bits on the physical
address space side

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