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

[bugzilla-daemon at libre-riscv.org]

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

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://bugs.libre-riscv.org
                   |                            |/show_bug.cgi?id=94

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #3)

> i am very wary of making any kind of changes to the Dependency Matrices.  it
> took months to get an understanding of them, enough to implement correctly.

(and it was 10 months ago.  sigh)

the load/store system is a *multi*-step process: there is the "normal"
(Register-FU and FU-FU hazard system, which takes care of the "usual"
register-based dependencies that all ALUs have including the Branch Unit),
*and* there is the inter-address LD/ST hazard Dependency Matrices.

the memory-function-unit matrices are augmented (differ from) the "normal"
register-style DMs in that they recognise 10 bits of the address as a way to
see if there was a conflict.  the logic being "overzealous".

you remember we discussed that last year, jacob, because 10 bits happens to hit
the 1 MEGABYTE boundary of Vulkan Texture blocks?

what i considered doing was having, instead of a straight 10-bit address-line
comparator, shifting that up by 4 bits and having a *bit-map* comparator for
the 4 LSBs.

in other words a byte LOAD would set 1 bit in the 16 bits, a half-word 2 bits,
and so on.  (actually to cover misaligned LOADs it would need to be a minimum
23 bits and/or split into *two* separate LOADs).

let us assume that the bitmap width is exactly the same as the cache line width
(16 bits representing 16 byte wide cache lines).

this bitmap - if filled by multiple LOADs - can have a popcount carried out on
it, and that tells us which "line" in the buffer has the highest number of
bytes to perform LOADs.

if the entire bitmap is all 1s, that is a full cache line of LOADs.

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