-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Monday, September 10, 2007 4:07 PM To: kmpark@infradead.org Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [PATCH 3/5] OneNAND support
In message 002501c7f347$e1d579c0$e1ac580a@swcenter.sec.samsung.co.kr you wrote:
...
+#ifdef __ARM__ +extern void memcpy32(void *, void *, size_t);
+static void *memcpy(void *dest, const void *src, size_t count) +{
- if (count < 32) {
unsigned short *_s = (unsigned short *)(src);unsigned short *_d = (unsigned short *)(dest);count >>= 1;while (count--)*_d++ = *_s++;return _d;- }
- memcpy32(dest, (void *)src, count);
- return (void *)count;
+} +#endif
Why exactly do we need this? And why do we need an additonal special function memcpy32?
It's for performance. Now ARM used the char-based memcpy. Even though it's working with current
char-based memcpy, I want to use the
optimized memcpy.
How much difference does this optimization make in real life? Do you have any time measurements at hand?
It's also discuss the at previous time http://sourceforge.net/mailarchive/message.php?msg_id=f3f1b91a0703141856n180...
I'm concerned about correctness. What happens in your coide when I write
memcpy (dst, src, 5);
How many bytes will be copied?
What happens when src or dst or both are pointing to odd addresses, i. e. in case of unaligned accesses?
Agreed
And basically OneNAND uses the 16-bit buswidth so we don't sure the correct behavior in OneNAND
BufferRAM if we use the char-based
memcpy.
I remember that ARM is terribly broken there... :-(
Memcpy32 is 32-bytes aligned optimized. Since we know the memcpy usages in OneNAND driver, we
guarantee the usage of memcpy32.
But the memcpy() you provide will also be used in all other partrs of U-Boot, won't it?
If you concern the portability issues, I can omit it at this time. How do you think about it?
Thank you, Kyungmin Park