We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
I have detected that some functions like this one are using their own XDATA space instead of using the XDATA_GROUP for local purposes:
for example this one:
void zmemcpy2(UINT8 *dst,const UINT8 *src, UINT32 len) { --dst; --src; while (len--) { *(++dst) = *(++src); } }
then this is the line in the m51 file:
XDATA 82C2H 000AH UNIT ?XD?_ZMEMCPY2?LIB
so then Im wasting ten bytes of global data space for just a memcopy. Why is this happening?
And here it is another weird thing: this function is never used by the rest of the program. It is compiled, but should not be linked. any idea?
thanks in advance...
"It is compiled, but should not be linked."
Only if you specifically request the removal of unused functions:
http://www.keil.com/support/man/docs/lx51/lx51_removeunused.htm
"Im wasting ten bytes of global data space for just a memcopy"
As the compiler already provides a ready-to-use memcpy, isn't the whole thing a bit of a waste...?
If a function isn't called and isn't removed, then the overlay analysis has no choice but to treat the function as a separate call tree with its own set of overlays. Uncalled functions thus waste a lot of data memory space. REMOVEUNUSED is a valuable linker option.
thank you,
I will try that REMOVEUNUSED option. I actually thought that it was a default option for any linker, so I am a bit confused about it. I've been reading that I have to use the extended linker lX51 and a very up-to-date version, otherwise that option is unknown.
About using our own memcopy2, its possible to write more efficient and smaller functions. OK its not an ANSI compliant, but it is a better choice for us.
Most linkers in my experience do remove unused code. This option is a new addition to the Keil toolchain, though.
(Thanks for putting it in, guys. It certainly made our life easier.)
Most linkers in my experience do remove unused code.
Actually not!
Some linkers ignores object files that are not referenced.
A linker is normally not able to know the contents of an object file and to surgically remove functions from it if not used. That is why most runtime libraries contains hundreds or thousands of tiny object files.
'51 compilers/linkers are a bit special because of the lack of real stack space, where the linker must analyse call chains for allocation of global parameter areas.
A Library is a special type of object file specifically designed so that the Linker can pick out only those functions that are actually required;
Otherwise, in general, if you tell a Linker to include an Object file, it will do so - it's up to you not to tell the Linker to link unused stuff!
Sergio Santos wrote: I've been reading that I have to use the extended linker lX51
This is true. the standard linker doesn't have the REMOVEUNUSED option. If you didn't buy the extended linker you can still use the demo version but it is code size limited.
fully stated: "so that the Linker can pick out only those modules containing functions that are actually required"
you can easily get 'unused functions' from a library if the modules there contain more than one function.
Erik
Hmm... what happened there? The text was all still there when I hit my 'Back' button.
So, let's just try that again:
"About using our own memcopy2, its possible to write more efficient and smaller functions."
Maybe it is possible - but have you checked whether what you've shown is actually any more efficent than Keil's?
If you're going for absolute efficiency, wouldn't you want to avoid generic pointers...?
Just a note about your copy. Note that the C standard specifies that you are always allowed to step the pointer one step past the last element of an array. However, you are not guaranteed to be able to step one step before the first entry.
On a different architecture, the processor could generate an underflow exception - even if you never try to use the decremented pointer. Even for a '51 it may be dangerous, depending on what "magic" the compiler vendor performs to implement generic pointers.