Re: How can I get this data into the .data section of the binary?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2020-06-21 6:55, Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> 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
       .      @       .