RE: [PATCH] riscv: lib: Optimize 'strlen' function

[David Laight <David.Laight@ACULAB.COM>]

From: Ivan Orlov
> Sent: 17 December 2023 23:23
> 
> On 12/17/23 18:10, David Laight wrote:
> > From: Ivan Orlov
> >> Sent: 13 December 2023 15:46
> >
> > Looking at the old code...
> >
> >>   1:
> >> -	lbu	t0, 0(t1)
> >> -	beqz	t0, 2f
> >> -	addi	t1, t1, 1
> >> -	j	1b
> >
> > I suspect there is (at least) a two clock stall between
> > the 'ldu' and 'beqz'.
> 
> Hmm, the stall exists due to memory access? Why does two subsequent
> accesses to the memory (as in the example you provided) do the trick? Is
> it because two "ldb"s could be parallelized?

On the fpga RISCV (and probably other 'small' implementations)
there is a two clock result delay from memory loads while the
result is written to the 'register file'.
ALU results get short-circuited so can be used in the next instruction.

The memory loads themselves are pipelined and can be issued
every clock.
(On the fpga version actual memory delays stall the pipeline.) 

...
> Maybe we could enhance it even more by loading 4 consequent bytes into
> different registers so the memory loads would still be parallelized?

You need the loads to be pipelined, not parallelized.
That will help if there are longer delays accessing cache memory.

I'd expect any cpu with (say) a 4 clock cache read latency to
pipeline reads so that one can be issued every clock provided
the results aren't needed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)