[PATCH] more problems with newlib/libc/machine/m68k/memcpy.S
Maxim Kuvyrkov
maxim@codesourcery.com
Wed Feb 10 14:47:00 GMT 2010
On 2/9/10 5:15 PM, Josef Wolf wrote:
> Hello folks,
>
> I have done a closer look at newlib/libc/machine/m68k/memcpy.S and I think
> there are a couple of problems with this code:
>
> 1. When the destination pointer is mis-aligned, up to three bytes are copied
> before getting into the optimized main loop. But d1, which contains the
> number of bytes to copy, is never adjusted to account for this fact. As a
> consequence, up to 3 byte too much can be copied by memcpy().
When destination is mis-aligned, D1 is properly adjusted here:
and.l #3,d0 | look for the lower two only
beq 2f | is aligned?
sub.l d0,d1
Or am I missing something?
>
> 2. When MISALIGNED_OK==0, no attempt is made to get the pointers to aligned
> positions. This results in much slower code than the old code for such
> CPUs. IMHO, the cause of the problem reported in the thread starting with
> http://sourceware.org/ml/newlib/2009/msg01079.html was mis-interpreted.
> The problem was _not_ the attempt to align dest. The problem was that
> even after dest was aligned, src was still not aligned. Thus, disabling
> alignment completely is the wrong response to that problem.
The problem was not misinterpreted; and it is true that memcpy can be
optimized for CPUs without alignment module by using 2-byte copies. It
is not straightforward to implement a single memcpy routine that will be
optimal for both CPUs that support unaligned accesses and those which
don't -- that is why I posted a simple byte-copy fix.
It seems that your patch lengthens the critical path for CPUs which
support unaligned accesses.
>
> 3. -mcpu32 seems to imply -mc68020. So the check for alignment capabilities
> gives a wrong result for cpu32. BTW: alignment capabilities depend not
> only on the CPU. It is also dependant on bus width and how the memory is
> connected.
Thank you for pointing this out.
Regards,
--
Maxim Kuvyrkov
CodeSourcery
maxim@codesourcery.com
(650) 331-3385 x724
More information about the Newlib
mailing list