[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 #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #7)
> one part that is very useful or required is for the decoder to determine
> exactly which registers each instruction reads/writes, instead of doing what
> we do (which I think is a major design flaw) where nothing knows exactly
> what registers will be written or not until the ALU finishes computing and
> sets the output valid flags.

you've completely misunderstood.  the decoder knows perfectly well which
registers are read and write: it has to.  i've just spent the past
three weeks making sure that it does.

here is the source code:

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

what you have completely missed is that the logic that was added right
back at the start - two years ago - is an opportunity for optimisation.

what you are describing as a "major design flaw" is a perspective that
is total nonsense.

let's go through it.

no FU can ever be permitted to operate without its write-hazards being
monitored.

therefore even if that Function Unit **MIGHT** write, the write hazard
**MUST** repeat **MUST** STILL BE REQUESTED.

this is blindingly obvious up to this point: failure to note any
hazards results in catastrophic unrecoverable data corruption.

now, it so happens that only the Function Unit itself can determine,
itself, whether things such as XER.SO actually need to be written,
because writing to XER.SO is determined from the *input*, which
is, clearly, NOT YET EVEN AVAILABLE at the time that the instruction is
actually issued.

therefore we are FORCED to make that write-reservation JUST IN CASE.

ONLY once the 64-bit result has been computed can the *PIPELINE*
determine - at that point and at that point only - whether XER.SO needs
to be written to, or whether it does not.

and if it does not, then this is great!  the write-reservation can be
dropped!

what that in turn means is that:

* a completely redundant (unnecessary write) to a regfile port is
  dropped.
* register file port pressure is consequently reduced
* the Function Unit may complete EARLY which in turn REDUCES
  the pressure on Function Unit Reservations
* with the pressure on Function Unit Reservations comes in turn
  the possibility of a Order (N^2) reduction in gate count of
  the Dependency Matrices due to a reduction in the number of FUs.

overall it is a SIGNIFICANT RESOURCE SAVING.  it is complete utter
nonsense to categorise such resource savings as "major design flaws".

this is just part of how the Power ISA works, and it is slightly
alarming to me that after two years you are not familiar with these
subtleties.

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