[patch] Fix and reenable memcpy/memset for m68k

[Kazu Hirata]

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