|
One embedded program has a MemCpy(), like:
void MemCpy(unsigned byte *pTg, unsigned byte *pSc, size_t slen)
{
volatile unsigned byte *ps, *pt;
for (pt=pTg, ps=pSc; ps<(pSc+slen); pt++,ps++)
*pt = *ps;
}
I wonder why the coder didnot use standard C memcpy function, what is the merit to rewrite a memcpy function like the above?
modified 4-Jan-13 14:46pm.
|
|
|
|
|
If this is connected to your question below, it is possible that the system available on the embedded device did not include a full standard C library. Alternatively this could just save using the library and thus reduce memory requirements.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Thanks, but according to the compiler manual:
//the compiler include the standard set of C library functions.//
I think which means the standard C function like memcpy should be accepted by the MCU, and the compiler is specific fot the MCU family.
|
|
|
|
|
Perhaps the library implementation is less efficient, you could look at the disassembly of the library memcpy() to find out. Or as Richard pointed out, maybe the person didn't want to deal with memory requirements of using the library.
|
|
|
|
|
Well, as I said before you are showing us a few lines of code and asking why it is done this way, but we do not have any information on the implementation of this product. You need to talk to the people who wrote this and ask them why they did it this way.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
econy wrote: I wonder why the coder didnot use standard C memcpy functio
1. They didn't know it existed.
2. The 'volatile' is important.
3. They thought 'volatile' was important. Perhaps due to the source of the pointers being passed.
4. They are doing a lot of very small copies and the compiler will optimize those with a user method but will not do so with a library method (it will always call the library method rather than attempting to unroll it.)
5. memcpy returns a value, the method doesn't. Perhaps that was important in terms of stack space.
6. The code was originally written with a very early version of the compiler and memcpy was buggy. Or the coder thought it was buggy. No one has challenged that since then.
Could also be a combination of the above.
|
|
|
|
|
For very small copies, this may be faster since it doesn't bother looking at alignment. However, if intrinsics are enabled, many compilers will identify the code as a copy and use an intrinsic instead (an inline memcpy.)
(See previous comment. Also note that years ago, especially for very small memory usage, many embedded developers wouldn't use the CRT; they wouldn't use libraries of any kind. This wasn't arrogance, but that they had to control every aspect of the code. Even today, I deal with many serious problems where third party libraries are used, including STL and Boost.)
modified 7-Jan-13 16:32pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
