[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Tue, 9 Dec 1997 12:24:00 -0600 (CST)
- From: joel at oarcorp.com (Joel Sherrill)
- Subject: memcpy performance
I have forwarded this to the newlib maintainers list for comments.
I have already been told there is a new and improved set of portable
memory functions in the current newlib source.
And before anyone asks .. no I don't have it either. :)
Joel Sherrill Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (205) 722-9985
On Tue, 9 Dec 1997, Eric Norum wrote:
> It's even worse than just a byte-by-byte copy!
> On the 971024 snapshot (gen68360 BSP) a call to memcpy produces:
> 1) A call to bcopy
> 2) The bcopy routine links a stack frame and calls memmove
> 3) The memmove routine:
> a) links a stack frame
> b) checks for overlap
> c) does a byte-by-byte copy
> 5 instructions/byte on a CPU32 processor!
> There's a heck a of a lot of unnecessary code here:
> Two extra function calls
> Two extra stack frames
> Extra code to check for overlap
> A very inefficient loop
> Processor-independent improvements required:
> 1) There should be an explicit memcpy routine.
> 2) The library should be compiled with aggressive optimization.
> Processor-dependent improvements that would be nice:
> M68k - The loop in memmove should be done in such a way that
> processors like the CPU32 can go into loop mode.
> Now all we need is a willing volunteer......
> Eric Norum eric at skatter.usask.ca
> Saskatchewan Accelerator Laboratory Phone: (306) 966-6308
> University of Saskatchewan FAX: (306) 966-6058
> Saskatoon, Canada.