Re: Record initialisation question

[DrPi <314@drpi.fr>]

Le 10/01/2021 à 23:14, Niklas Holsti a écrit :
> On 2021-01-10 23:27, DrPi wrote:
>> Le 10/01/2021 à 20:30, Niklas Holsti a écrit :
>>> On 2021-01-10 18:53, DrPi wrote:
>>>> Le 09/01/2021 à 16:44, Niklas Holsti a écrit :
>>>     ...
>>>>>
>>>>> Do you expect the compiler/linker to generate the full value of the 
>>>>> Dcd object into the program image at compilation and link time? 
>>>> That's it.
>>>>
>>>>> Have you ensured that the construction of the Dcd object requires 
>>>>> no elaboration code? Most Flash memories cannot be written in the 
>>>>> same way as RAM, so even if that .txt section is not 
>>>>> write-protected, normal RAM-oriented elaboration code would not be 
>>>>> able to write into Flash.
>>>> I'm aware of this (I'm an electronics guy).
>>>> I'll add a "pragma No_Elaboration_Code_All;" when I'm ready.
>>>
>>>
>>> Better add it now, because if you add it later, the compiler may then 
>>> complain that it cannot implement the Dcd aggregate without 
>>> elaboration code, and you will have to work around that somehow.
>>>
>>> A good while ago, a colleague had a problem where a large constant 
>>> array aggregate would require elaboration code if written in named 
>>> form (Index => Value, Index => Value, ...), and it was necessary to 
>>> write it in positional form (Value, Value, ...) to get rid of the 
>>> elaboration code. It can be tricky, so it is better to be warned 
>>> early of any problems.
>> Thanks for letting me know.
>> Any reason why the behavior changes with the way of writing ?
> 
> 
> Not really. We asked the compiler vendor (not AdaCore) for help, and 
> they advised us to use the positional form, without further explanation. 
> I assume the compiler writer just did not bother to implement the 
> index-sorting step that would be needed for the named form, and 
> preferred to generate elaboration assignments "on the fly" in the order 
> the indices appeared in the named aggregate.
> 
> The point is that compilers are not required to make all things work 
> without elaboration code. Just as for record representation clauses, 
> compilers are only required to reject the program if the compiler cannot 
> (or does not bother to) implement the request. So you seldom know if 
> your request will work, until you try it with your particular compiler.
> 
> I am reminded of a similar problem I had (this time with GNAT) more 
> recently: I wanted to write start-up code to initialize the DRAM 
> controller, but of course this code should normally not use the DRAM, 
> only registers. I had nice record types for the DRAM controller 
> registers, but any use of record aggregates on the right-hand side of 
> assignments made GNAT use temporaries in the stack (thus in DRAM). Only 
> for an assignment of a literal constant would GNAT build the constant in 
> registers, avoiding DRAM use. (In the end I used the record aggregates, 
> because I knew that the DRAM controller would have some working initial 
> state left over from the boot SW, and I only needed to modify this state 
> a little.)
> 
Thanks, that's interresting.
I added "pragma No_Elaboration_Code_All;" to my code and... all records 
are rejected.
The boot data structure (in FLASH memory) is composed of several 
records. They are linked by their addresses. When a record contains an 
address, initializing it with a "non static number" value makes the 
compiler complain (with No_Elaboration_Code_All set).
You were right.
I have to find a workaround.