Re: Size optimization for objects

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:b4791rF6i9hU1@mid.individual.net...
> On 13-07-10 13:57 , Rego, P. wrote:
>>>> and the read size of bla.o is 611 bytes.
>>> What do you mean by "read size"? Perhaps this is a typo, and you meant
>>> to write "real size"?
>>> If you mean the total size of the file bla.o (from the directory
>>> listing, e.g "ls -l"), this is not a useful comparison, because the file
>>> contains much more data than just the machine code: there are headers,
>>> symbol tables, and other debug information -- among other things, the
>>> information that "nm" uses to associate machine code addresses with
>>> identifier symbols.
>>
>> Yes, it is from directory listing. In this case, the 'size' provided
>> by "ls -l" should be bigger, right?
>
> Yes, if you consider only the size of the code ("text" segment). For
> data, if the program contains uninitialized, statically allocated
> variables, the file size can be smaller than the "memory image" size,
> because the .o file only describes those variables (name, size, address
> or offset) but does not provide values for the variables.

To provide a bit more background: the size of an .o file is correlated to 
the associated code size, but it (probably) has no relation to the data size 
at all.

(I'm going to explain how Janus/Ada and some ancient C compilers handled 
these files; I would expect GCC and GNAT to be similar, but I don't know for 
certain.)

.o files have a bunch headers and typcially three segments: .text (which 
contains code), .data (which contains *initialized* data), and .bss (which 
contains *uninitialized* data). There is also some relocation information 
for the code, so the .o file is generally quite a bit larger than contained 
code alone.

For Janus/Ada, we put values of *constants* (string literals, float 
literals, static aggregates, etc.) into the .data segment, but not any 
variables. Those all go into the .bss segment. (We did that to support 
putting the code and constants into EEPROM; the data (in the .bss) is the 
only part that has to be mapped to RAM.)

The .data segment is also present in its entirety in the .o file (it has to 
be, in order to have those initial values). But the .bss segment is just a 
header specifying it's size; it has no contents at all and thus contributes 
almost nothing to the size of the .o file.

So for Janus/Ada, an .o file is code size + constants size + headers. The 
data size doesn't have any impact on the .o file size at all. It's possible 
that GNAT might put some initialized things into the ".data", but I highly 
doubt it would do that for anything that is really uninitialized.

Hope this clarifies things.

                                             Randy.