[libre-riscv-dev] LD/ST address matcher

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Jun 5 08:13:09 BST 2019


On Wed, Jun 5, 2019 at 7:58 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Tue, Jun 4, 2019, 23:39 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > On Wednesday, June 5, 2019, Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > Note that texture access is just one of the places that memory is
> > accessed
> > > in sequence separated by exact multiples of 1 MiB.
> >
> >
> > Then in all of those places, the question (which has not been answered)
> > applies to all of them.
> >
> > To make the question clear: does striping occur in all situations?
> >
> To make the answer clear: that depends. It definitely can, and will, in a
> lot of cases, but there are important cases where it won't. Being able to
> skip checking the upper bits of the physical address depends on how big the
> performance penalty is (both ways), which I have not calculated.

 we need to investigate this fully, and properly.

 it occurred to me that even in the interleaved example, the first
time round the loop j there would be a clash, causing one of the two
LDs to stall (by one cycle).

 on the subsequent time round the loop, the first LD (still
outstanding) would NOT clash with the LD of the *second* loop, because
the lower bits of the address would miss in the 16-bit bitmap
(representing the lower 3 bits of the address).

 so as long as we have 4-way multi-issue LD/STs (or better, however
that's a hell of a lot), it's fine, as i think we can tolerate a
single cycle (or two) latency on a 1,000 long for-loop.

l.



More information about the libre-riscv-dev mailing list