From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal 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: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How can I get this data into the .data section of the binary? Date: Sun, 21 Jun 2020 09:55:16 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net by64Pz8tpf0ezFSVD4+mBQcvNtjfy8Q+QQ66ZO/fyaTkDVaUEO Cancel-Lock: sha1:Ik8do3t6R1NnlzzRggj1sn774/o= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:59136 List-Id: On 2020-06-21 6:55, Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:hl0s14FsgcgU1@mid.individual.net... >> On 2020-06-18 5:55, Randy Brukardt wrote: > ... >>> The better question is why you care? >> >> >> [snip] >> >>> (The situation can be different on a bare machine, of course.) >> >> > ... >> For my case of the large constant array, we needed to save RAM space, and >> did not want to spend RAM _both_ for the elaboration code that initialized >> the array (larger than the array itself) and for the array. > > I suppose it would depend on the declaration of the array, but I would not > expect that to be the case most of the time. Typically, one can initialize > most Ada data types with a block-copy, which would only be a handful of > bytes on most target machines. I'm sure you are right, most of the time. In our case, however, even if the compiler would have done a block-copy, the *source* of the block-copy would also have been in RAM because the *whole* SW image was copied at boot from EEPROM to RAM (as is ESA practice). So the RAM consumption of the array would still be at least twice the array size. A block copy from EEPROM to RAM would have been ok, in principle, but in our case the compiler/linker knew nothing about the program's EEPROM residence. That was Boot SW business. And if the compiler could have created the static source data for a block copy, it could as well have placed the whole load-time initialized array (a constant) in the read-only-data segment, which was what we wanted, and got in the end. This was in the days when RAM in ESA on-board computers was expensive static RAM; nowadays it is usually dynamic RAM, I believe, and typical RAM size has gone up by one or two orders of magnitude. -- Niklas Holsti niklas holsti tidorum fi . @ .