[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 #3 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jacob Lifshay from comment #2)
>
> Ok. The algorithm I proposed can still be used for scheduling loads/stores
> inside each batch and deciding which cache line to access each cycle, since
> I think the memory dependency matrix currently handles deciding which ops to
> execute each cycle by relying on a slow and simple FIFO algorithm. 

nono, it's a bitlevel matrix, capable of multi issue execution and resolving
all conflicts and dependencies in a single cycle.

the ordering is preserved by cascading bits being raised, just like in the
Register-style DMs.

so yes it has the same *characteristics* ad a FIFO bit is not a sequential
binary numbered array, it is *unary* numbering, and the bits (SR Latches)
specify "row X is in front of column Y".  actually, "row X is a memory LD
hazard on column Y"

> The queue
> in the algorithm I proposed can be the same HW as the memory dependency
> matrix, so it would end up as a hybrid algorithm.

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.

using them as-is, as a component: no problem.  modifying them? no - not at this
stage, we simply haven't got time.

> The recursive summary mechanism inspired by carry lookahead will still be
> useful.

can you do this piece? if we spec it up. i can point you at the code it needs
to connect to (minerva L1 cache and LDSTCompUnit).

-- 
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