Re: [patch, mips, memmove] Remove memmove's use of memcpy on MIPS

[Steve Ellcey <sellcey@mips.com>]

On Fri, 2013-01-25 at 13:55 -0500, Chris Metcalf wrote:

> 
> See ports/sysdeps/tile/tilegx/memcpy.c for how the tile architecture handles this issue.
> The memcpy code advances until the destination pointer is cache-aligned, then loops cacheline
> at a time, first reading 64 bytes, then doing the prepare-to-store (aka "wh64"), then writing
> all 64 bytes.  This ensures that no matter what overlap the source has with the destination,
> we have captured any data that might be overwritten by the "wh64" instruction.  Since our memory
> architecture is non-blocking we can issue all eight reads without waiting for them to complete.
> 
> Would doing something like this for MIPS allow your memcpy to be safe for forward memmove?

I like this implementation, unfortunately I don't have a
CHIP_L2_LINE_SIZE macro to check the cache line size and my cache line
size could be anywhere from 16 to 128 bytes.  I currently optimize for
32 bytes but make sure it works correctly for anything less then 128
bytes.  I like the use of 'safe' prefetches when you can't use 'wh64'. I
may experiment and see if I can create a C version of memcpy like you
have that works as well or better then my existing asm version, but the
use of the MIPS partial word loads (lwl/lwr, ldl/ldr) in my assembly
version may make it difficult, or at least make it require more inline
assembly.

I think I still need to check in my current patch for now to fix ToT
memmove while I look into making a better memcpy.

Steve Ellcey
sellcey@mips.com