[U-Boot-Users] [PATCH 3/5] OneNAND support

[Wolfgang Denk <wd@denx.de>]

In message <003101c7f37f$1fcb6cd0$e1ac580a@swcenter.sec.samsung.co.kr> you wrote:
> 
> > > > > +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;
> > > > > +	}
...
> > 
> > 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=f3f1b91a0703141856n1807b799pfd8ffb4783ff0804%40mail.gmail.com

Now I remember, thanks for the link.

> > 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

If my interpretation is right, that above  implementation  will  copy
only  4  bytes  when  I  ask  for  5 to be copied, then the answer is
simple: fix it, or dump it.

> > 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?

Portability is one thing, but it seems to be not correct, which is a
strict No, No to me.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Severe culture shock results when experts from another protocol suite
[...] try to read OSI documents. The term "osified" is used to  refer
to  such  documents. [...] Any relationship to the word "ossified" is
purely intentional.                                - Marshall T. Rose