[libre-riscv-dev] [Bug 216] LOAD STORE buffer needed

[bugzilla-daemon@libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=216

--- Comment #12 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
jacob i'm extending the LD/ST-address-conflict matrix to unary-overlap in the
last LSB 4 bits of the address.
an unary map (LD byte == 0b0000 0000 0000 0001, LD dword = 0b0000 0000 1111
1111)
then shifted up by the LSBs of the address, and split into two (if there is
a misalignment), means that two bit-level comparisons detect if the LDs overlap
in the last 4 bits of the address.

the current system already compares bits 4 thru 11 as an *binary* address.
by combining with the unary system it gives a full guaranteed detection
of overlap, based not just on the address but on the length of the operation.

however that leaves the top bits (11 thru 39 or 48, whatever we decide the VM
page size to be).

and that can be taken care of by a 4 or 8 entry mini-L1-cache-aka-LD/ST-buffer

however what is nice is that the mini-L1-cache can:

a) use the fact that the address-conflict matrix has *already* detected
(compared) addresses in bits 0-11

b) find those addresses which *are* equal (in bits 4 and above)

c) make sure the upper bits (11+) are also equal

d) use a merge of the *unary* maps of bits 0..3 to detect which LDs/STs are
covering the same L1 cache line, for all addresses detected in (b+c)

the unary map "merge" is where a popcount will tell us which is the best one to
put straight through to the L1 cache.  if all 16 bits (when merged) are set, we
know that's a full cache line.

the nice thing is, it's not actually that complicated.  we don't want to make
the *entire* L1 cache line this (hence a mini-pre-L1-cache) because it would
mean a popcount function on absolutely every single line of the L1 cache, and a
lot more besides.

plus, an "optimisation" is that for those address bits 4-11, well, because
we've already compared them, instead of doing the comparison again, we can use
the *conflict matrix row number* as a substitute.  i think.

i have to check that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev