Re: [patch] Fix and reenable memcpy/memset for m68k

[Kazu Hirata <kazu at codesourcery dot com>]

Hi Eric and Joel,

> > Just to finish this one completely off.  I want to let you know that I 
> > pinged Eric Norum
> > to review this because he was responsible for the m68k specific memcpy 
> > RTEMS uses.
> > Where possible we prefer to use newlib code instead of overriding it 
> > with our own
> > version.   We are inclined to switch to your implementation but I would
> > appreciate you reviewing to the attached memcpy.c to see if Eric had any
> > optimization ideas that aren't also in yours.
> >
> > FYI parts of the RTEMS build structure can distinguish CPU models at a 
> > finer
> > granularity than  multilib allows.  The attached memcpy.c has some 
> > optimizations
> > to account for the CPU32+.
> > Thanks.
>
> The optimization in question is to put the CPU32+ (and 68010 if there 
> are still any of those in the wild) into 'loop mode'.  This is a special 
> case of a single two-byte instruction followed by a dbra.   This allows 
> the CPU to repeatedly execute the two instructions without any 
> instruction fetch cycles.  Thus, the assembly code from Kazu Hirata 
> actually incurs a performance penalty by unrolling the loops.
> Whether or not this optimization is worthwhile adding is left as an 
> argument for others to decide.   Are CPU32+ architecture machines even 
> available any more?

Honestly, I didn't know anything about CPU32+.  If the architecture is not 
common these days, I think the unrolled version of memcpy is OK.

Kazu Hirata