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 am a student from germany and I am working on a project with KeilC an uVison. I have a strange problem. - I get some C-code for a 8051 compatible - this code has extern linker files - the current code compiles without errors - after compiling I see some size-values for DATA,XDATA,PDATA - if i want to shrink the code by deleting or uncommenting some lines the linker throws errors, because the size of data exceed the restrictions by the linker file.
I do not understand, why the code size increases if I shrink the code? Can some one explain me this issue?
Thank you for help, Regard Chris
In "nice" programs, you can't call a function without using the name of the function.
It's not quite as simple as that. There's a good deal of ground between calling a function directly by name, and reaching a call to it in some tricky, circuitous way that involves the function's name only several steps away from the actual call.
That would make it simple for the linker to know if a function is used or not.
Not really. In all but the most strictly simple designs there are usually things like callbacks, function pointer tables, or others that the linker can't generally follow. There would be only one conclusion safe for Lx51 to make, in such a situation: that all functions whose address is ever taken and stored somewhere will be running currently both to each other, and to the whole "straight" call-tree. So they would each have to get their own call-tree and variable store. Basically, as soon as a single function pointer is used anywhere in the program, Lx51 would have to turn off overlaying forcibly.
Keil C51's approach to this (warn the user, and let him deal with it) is IMHO a good match to the '51 controller's inherent limitations.
Note that callbacks, function pointer tables etc are normally referencing the name of the function, making the linker see that there was a reference to the function, even if the linker can't know if the code will actually make use of this reference.
For a linker, it really does not matter if the function name is referenced several steps away. Just seeing any reference to the function is enough for the linker to drag in the function and - if the MAP file supports it - mark the function as used.
That means that for a "nice" program, the linker will always be able to see a reference to the symbol of the function. But as I mentioned, "non-nice" applications may have placed the function at an absolute address, and then created a direct or indirect call to the function based on this hard-coded address. And a "non-nice" program may place two functions after each other in the same source file, and make a jump/call n bytes past the end of the first function.
A PC program should/must always be nice and never access function without referencing a symbol that makes the linker know what to add to the binary.
An embedded system is quite often not nice. You seldom have a need to make jumps relative the location of another function, but interrupt vector tables, flash sectors etc may be big reasons for placing functions at absolute addresses. And as soon as a function is placed at an absolute address, it will be impossible for the linker to know if other parts of the application, a boot ROM or some hard-coded interrupt logic may perform direct jumps to these addresses.
That is the reason why an embedded linker has to assume that there are unknown code paths reaching the function even if the linker can't see any reference to the function. The linker just can't know if the chip is programmed with a separately linked boot monitor, or if the specific chip has an unusual vectored interrupt system. The calls to absolute addresses may seem "non-nice" but are no different from the normal BIOS calls in a PC.