Byte-misaligned memcpy problems

[eric at skatter.USask.Ca (Eric Norum)]

Joel Sherrill <joel at oarcorp.com> wrote:
> + where this stuff should go in the tree.  Suggestions include:
> - score/cpu
> - lib/libc
> - lib/libcpu  (my preference)
> - BSP
> + do we remove the m68k specific memcpy we added to newlib or fix
> it? + do we disable newlib from building a memcpy?

Until I read the message from Chris Johns about implementing memcpy  
using a DMA controller I would have said the correct place was in  
score/cpu, just to make sure the correct version is always used -- so  
that a pathological order of libraries didn't bring in a bad copy  
from newlib.  Yes, this does add more code in the base set, but it's  
a pretty small routine.......

It could be in the BSP to allow for the presence of  
hardware-specific support., but I think that this is special-purpose  
enough to require either a different name or special work on the part  
of the implementor.  (BTW -- how does the IDMA version work in the  
face of preemptive multitasking?  I would think that the overhead of  
mutexing the DMA controller would overwhelm any speedup from running  
the memcpy in hardware....  and what does the CPU do while the DMA is  
running?).

To make a very long story short, my vote is for:
	1) Put m68k-specific version in score/cpu.
	2) Remove m68k-specific version from newlib.
	
Item (1) should include modifying the source so the conditional  
compile depends on
	#if (M68K_HAS_MISALIGNED == 0)
	

I apologize for confusing the issue by implying that egcs generated  
CPU32+ code when given -mcpu32.  I should have checked first and  
would have seen that -mcpu32 produces code good for either CPU32 or  
CPU32+.

---
Eric Norum                                 eric at skatter.usask.ca
Saskatchewan Accelerator Laboratory        Phone: (306) 966-6308
University of Saskatchewan                 FAX:   (306) 966-6058
Saskatoon, Canada.