[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 #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #5)
> (In reply to Luke Kenneth Casson Leighton from comment #4)
> > https://groups.google.com/g/comp.arch/c/vdgvrYGoxTM
> > 
> > need help, asked on comp.arch :)
> 
> Google finally fixed Google Groups so it's archivable on archive.org!

bout time, it's big enough and dignificant enough, good for them.

so after going round the houses a bit on comp.arch it looks like a counter
and/or bitfield per reg on WaW is the way to go.  as it is r9-r9 or r3-r3 the
number of columns i *think* only need be 1 i.e. it is a WaW vector more than it
is a matrix.

allocating an entirely new virtual row in the FU-REGs per newly-discovered WaW
conflict gives us a safe rollback/shadow-commit even when faced with WaW
hazards.

the FU-REGs itself stores all Write Hazards and by ORing all write hazards
together down the columns we get a "Write Hazard Vector".

this can be ANDed with our instruction's write reg target to tell us that a WaW
exists.

normally (in the 6600) this would be an indication to issue to "stall".  we
instead use this to increment that reg's "rename" counter.

this just leaves a multi-issue-capable method of transmitting and marshalling
read/write regfile ports and addresses.  which is the bit i am still going
"hmmm" on.

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