This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data Space grows unexpectedly

Hi all,
I've noticed something strange with one of
my 8051 projects. When I build the project, the build results show that I have used 98 bytes of data space. If I add the statement while(1) {} to the beginning of main(), my data space useage goes up to 161!, which is too much to fit in my SiLabs MCU.
If I move the while(1) statement down further in main(), the data useage starts getting less, until it reaches the original 98 when the while statement is placed at the very end of main(). Also, the statement while(0) {} does not cause any change in the data space useage value, regardless of where it is placed.

What is causing this wierd behaviour?

Thanks for all your help.
Tony

  • Optimization? Good point. But putting a while(1){} statement at the beginning of main should allow the optimizer to eliminate unused code and variables after the location of the while(1) statement. Instead, 63 more data space variables are allocated!

    Tony

  • optimizers are funny things, they do some thing well and screw up royally on others. this is not a Keil thing, it is an optimizer thing.

    One guess : what if calls are optimized out, but called routines (in another module) are not. That would explaim it. Do you have L16 linker warnings?

    Erik

  • Erik,
    Thanks for your reply. Yes, I do have L16 warnings, and I have many more when I include the while loop in main()!

    What exactly is the L16 warning telling me? I never fully understood this, and would really appreciate a clear explaination of it.

    Thanks in advance.
    Tony

  • What exactly is the L16 warning telling me?

    That you need to consult the documentation on the topic of memory overlaying.

    Basically, the linker tries to figure out the calling relationship between functions. If there are two functions that do not call each other, then the local variables of these functions can be overlaid i.e. they occupy the same physical locations in memory.

    Uncalled functions are a problem. The linker has no way of knowing how they are called (from assembly ? through function pointers ?) and therefore has to put their local variables in unique memory location, which vastly inflates the amount of memory used.

  • OK, thanks folks. I think I have a handle on my problem now. I will experiment with the optimizer and work on the L16 warnings to see if I can prevent my data space from overflowing.

    Thanks again all,
    Tony

  • The while(1) will cut off potentially many function calls from the call tree:

    A();
    while (1);
    B();
    C();
    D();

    B, C, and D will thus become roots of their own call tree, and any data memory needed by those call trees cannot be overlaid with that of the one with root at main (or A).

    while(0) does not have this effect, because it does not prevent the flow of control from reaching the later functions.

    The optimizer will eliminate the calls to B, C, D. But the linker will have to eliminate the body of those functions. Either each function must be in its own C file (so that each winds up in its own segment) for the linker to omit the unneeded functions, or the new REMOVEUNUSED directive must be used with the linker to get rid of the uncalled code.

  • Drew,
    Thanks for that clear explaination. Now I see why as I move the while(1) statement further and further down in main(), my data space useage gets smaller and smaller.

    Thanks again all.
    Tony