[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 #2 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
ok, i thought a bit more, and i don't believe this idea will be useful
in exactly the way that it is originally envisaged (if i understand it
correctly), and it's quite simple: it would only be useful for instructions
that have one read (and no writes) or one write (and no reads).

direct-and-only association of FU-with-a-reg is a severe restriction.
at present there are some FUs with *six* read registers.  actually,
seven

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/cr/pipe_data.py;hb=HEAD

  10     regspec = [('INT', 'ra', '0:63'),      # 64 bit range
  11                ('INT', 'rb', '0:63'),      # 64 bit range
  12                ('CR', 'full_cr', '0:31'), # 32 bit range
  13                ('CR', 'cr_a', '0:3'),     # 4 bit range
  14                ('CR', 'cr_b', '0:3'),     # 4 bit range
  15                ('CR', 'cr_c', '0:3')]     # 4 bit: for CR_OP partial
update

(there are also 3 output regfile ports on CR: this allows transfer in
from RA to CR and from CR to RT)

the SPR regspecs are six in and six out:

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/spr/pipe_data.py;hb=HEAD

  19     regspec = [('INT', 'ra', '0:63'),        # RA
  20                ('SPR', 'spr1', '0:63'),      # SPR (slow)
  21                ('FAST', 'fast1', '0:63'),    # SPR (fast: LR, CTR etc)
  22                ('XER', 'xer_so', '32'),      # XER bit 32: SO
  23                ('XER', 'xer_ov', '33,44'),   # XER bit 34/45: CA/CA32
  24                ('XER', 'xer_ca', '34,45')]   # bit0: ov, bit1: ov32

the reason why there are six is because mtspr needs to construct
(or change) the three XER registers.

there are *six* separate regfiles, a seventh is necessary for the FPR
and an eigth is under consideration (MSR bits, similar to XER bits)
to speed up context-switching (writing MSR.pr as its own bit instead
of to the entire MSR) and other operations.

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/regfile/regfiles.py;hb=HEAD

   6     * INT regfile   - 32x 64-bit
   7     * SPR regfile   - 110x 64-bit
   8     * CR regfile    - CR0-7
   9     * XER regfile   - XER.so, XER.ca/ca32, XER.ov/ov32
  10     * FAST regfile  - CTR, LR, TAR, SRR1, SRR2
  11     * STATE regfile  - PC, MSR, (SimpleV VL later)

given the heavy level of inter-connectedness across each pipeline between
different regfile types, it is simply not practical to consider allocating
one entire regfile for the entire lot, in order to have a single FU deal
with a single register.

all the ALUs use (update) XER and CR.  even LD/ST requires the addition
of XER.SO and CR (which will be... complicated)

  23     regspec = [('INT', 'o', '0:63'),   # RT
  24                ('INT', 'o1', '0:63'),  # RA (effective address, update)
  25                # TODO, later ('CR', 'cr_a', '0:3'),
  26                # TODO, later ('XER', 'xer_so', '32')

this is to be able to support the arithmetic ld/st (and cix)
instructions properly, which set CR0 and therefore also set XER.SO
which i can tell you will be a royal pain given that LDSTCompUnit
is a special (non-standard) FU.

bottom line is that due to the supercomputing nature of Power ISA,
the idea of dedicating one single virtual in-flight regfile entry to
one single Function Unit is a non-starter.

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