Tue Mar 1 21:07:00 GMT 2011
On 02/28/2011 11:51 AM, Schwarz, Konrad wrote:
> GCC generates calls to memcpy() to implement assignment of structures larger than some internally-defined size. After studying the manual, I am convinced it is not possible to turn this off. GCC requires the standard library to provide these routines.
FWIW it seems GCC for PPC in current SVN trunk has the
-mblock-move-inline-limit= option that lets the user control when a call
to memcpy is emitted. But maybe this flag is more recent than your
version of GCC.
> For a 32-bit implementation, in particular in the e200 series of cores, the 32-bit only store/load multiple word instructions are a convenient and fast way of context switching the 32-bit portion of the task context; to keep interrupt-service-routine latency low, only the minimal context should be saved when entering an ISR, which is also handily achieved by the load/store multiple word instructions; ISR authors can't be faulted when GCC emits calls to memcpy()--it is not even clear when exactly GCC will do this.
I would argue that ISR authors can't be faulted for calling memcpy
But the version of memcpy called from ISR context may well need to be
different from the memcpy in user space context: different context,
> A memcpy() that traps and causes each task to aquire extended context is of questional value anyhow for predominantly integer code.
Do you mean in general, or for your particular combination of CPU, OS
Just my opinion, but I think it really depends a lot on the workload,
and how well the OS/environment (ISR handlers, context switching)
For instance, the context switching code may well reset the status
register after a while, so there is no need to use an extended context
until the next call to memcpy.
That said, I have no idea what approach is best in the common case, so
you may well be right that it's not optimal.
More information about the Newlib