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

Compiled object size

I have a few source files in which some const variables are required (same for all of those source file).

In the provided framework there is a .hpp header file that includes definitions (not only declarations) of those variables and this header is included in my source files mentioned before.

Then I realized, that each of my source files contains a copy of that RO data const variable, so in order to reduce memory footprint I made one more .hpp that is included in my source files and which contains extern references to those variables (included somewhere else) without actual variables.

I compared build .o object information provided below:

(note: RW, ZI removed)

Not using externs, using actual variables:

Code: 1192

(inc. data): 84

RO Data: 144

Using externs without actual variables:

Code: 1392

(inc. data): 216

RO Data: 144

1) Why code size increased?

2) Why inc. data increased?

3) In this case, why RO (const data) size didn't change?

4) What is inc. data in this scope?

Parents
  • Hi,

    I believe that your results may be a consequence of the way that ARM code accesses variables. In order to access a data item in memory, the program must first load the address of that item into a register. If other variables are in the same compilation unit, they may be able to be accessed using the same pointer as a base address and simply adding an offset. In this case, there is no need to load further addresses to access these other variables. The compiler can make this assumption because it knows that variables in the same compilation unit will be located in the same memory region at runtime and it also knows the layout of that region. The base address will be embedded into the code section as a "literal pool" of data and loaded at run-time using PC-relative addressing.

    If the variables you are trying to access are "extern" then the compiler can make no assumptions about whether they can be accessed using a common base address. In this case, it must load a separate base address for each one. These addresses need to be stored separately in the code section and loaded separately.

    So, if all your variables are extern:

    - the code size will increase as extra instructions will be required to load each new base pointer

    - the code size will increase because it needs to contain all these separate base pointers

    The "(inc data)" figure gives the amount of literal data which has been embedded in your code section. The increase will be due to the extra pointers.

    One way around this is to put all your external const variables into a structure. That way, the compiler can assume that all can be accessed via a single base address. This will reduce the number of instructions used and the size of the data included in the instruction region.

    I hope this helps.

    Chris

Reply
  • Hi,

    I believe that your results may be a consequence of the way that ARM code accesses variables. In order to access a data item in memory, the program must first load the address of that item into a register. If other variables are in the same compilation unit, they may be able to be accessed using the same pointer as a base address and simply adding an offset. In this case, there is no need to load further addresses to access these other variables. The compiler can make this assumption because it knows that variables in the same compilation unit will be located in the same memory region at runtime and it also knows the layout of that region. The base address will be embedded into the code section as a "literal pool" of data and loaded at run-time using PC-relative addressing.

    If the variables you are trying to access are "extern" then the compiler can make no assumptions about whether they can be accessed using a common base address. In this case, it must load a separate base address for each one. These addresses need to be stored separately in the code section and loaded separately.

    So, if all your variables are extern:

    - the code size will increase as extra instructions will be required to load each new base pointer

    - the code size will increase because it needs to contain all these separate base pointers

    The "(inc data)" figure gives the amount of literal data which has been embedded in your code section. The increase will be due to the extra pointers.

    One way around this is to put all your external const variables into a structure. That way, the compiler can assume that all can be accessed via a single base address. This will reduce the number of instructions used and the size of the data included in the instruction region.

    I hope this helps.

    Chris

Children
No data