From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.bbs-scene.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Size optimization for objects Date: Thu, 11 Jul 2013 19:35:23 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <9cbe0ad4-f54c-4c99-ba58-4db027ae962e@googlegroups.com> <70b1d2b0-d5ab-431e-84b9-9f00af08dbe2@googlegroups.com> <91dea591-19d5-484d-a13d-db86bbf0b3b8@googlegroups.com> <24223a1d-b350-4289-9d35-7ab197349e96@googlegroups.com> <63b8f2ef-5f9b-45b5-8d40-2eec7f32f11b@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1373589323 29130 69.95.181.76 (12 Jul 2013 00:35:23 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 12 Jul 2013 00:35:23 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Original-Bytes: 4344 Xref: number.nntp.dca.giganews.com comp.lang.ada:182480 Date: 2013-07-11T19:35:23-05:00 List-Id: "Niklas Holsti" 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.