From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!news.szaf.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Record initialisation question Date: Mon, 11 Jan 2021 00:14:45 +0200 Organization: Tidorum Ltd Message-ID: References: <5ff9779d$0$24281$426a74cc@news.free.fr> <5ffb311f$0$16185$426a74cc@news.free.fr> <5ffb7135$0$24247$426a74cc@news.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net WMp20jEignm4kNDlJhBbVgqAAtUfOd5guzB6eY1y3z+o1c7Da0 Cancel-Lock: sha1:PH5RfI2C0/E9BkGhv90ocj+zOy4= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-Reply-To: <5ffb7135$0$24247$426a74cc@news.free.fr> Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:61095 List-Id: 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.)