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: Thu, 14 Jan 2021 16:27:09 +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> <5ffc8efd$0$8957$426a74cc@news.free.fr> <60004212$0$13563$426a34cc@news.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net eDGX9WUw55vQ7WCDyKGezAe7LoIJBtFoLixKXoby6fQxKcyGw1 Cancel-Lock: sha1:SiVwHtuA8w4fF1a3gxroHA8mE5w= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 In-Reply-To: <60004212$0$13563$426a34cc@news.free.fr> Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:61127 List-Id: On 2021-01-14 15:07, DrPi wrote: > >> The problem is that "static" in Ada means "known at compile time", >> while addresses, although static in execution, are generally not known >> until link time. A case where assembly language is more powerful :-( >> > Or C :( > I use the manufacturer C code generated by their tool as reference. In > C, initializing a structure element with an address is not a problem. The C compiler emits a relocatable reference to the addressed object, and the linker replaces it with the absolute address. An Ada compiler should be able to do the same thing when the address of a statically allocated object is used to initialize another statically allocated object, assuming that the initialization expression is simple enough to require no run-time computation. Perhaps part of the reason why that does not happen is that System.Address is a private type, and might not be an integer type. Do you (or someone) know if the C language standard guarantees that such initializations will be done by the linker, and not by the C start-up code that is analogous to Ada elaboration code? Can you ask your Ada compiler vendor for suggestions? Assuming you have support from them. >>> I have to find a workaround. >> >> If addresses are the only problem, and you are in control of the flash >> memory lay-out, you might be able to define static Ada constant >> expressions that compute ("predict") the addresses of every boot data >> structure record. But those expressions would need to use the sizes of >> the records, I think, and unfortunately the 'Size of a record type is >> not a static expression (IIRC), and that may hold also for the >> GNAT-specific 'Max_Size_In_Storage_Units. > > I can redefine the records with UInt32 instead of System.Address. The > problem is : What is the expression to convert from Address to UInt32 > without using a function ? You could try Unchecked_Conversion or System.Storage_Units.To_Integer. But my suggestion did not involve such conversions: I assumed that you would be able to compute, using static universal-integer expressions, the addresses for all your flash objects, and use those directly in the record aggregates. This assumes that you are able to define the lay-out of all the stuff in the flash. You might then also specify the 'Address of each flash object, using those same universal-integer expressions. Something like this (not tested with a compiler): Flash_Start : constant := 16#500#; Obj_A_Addr : constant := Flash_Start; Obj_B_Addr : constant := Obj_A_Addr + 16#234#; -- Here 16#234# is supposed to be the size of Obj_A, so that -- Obj_B follows Obj_A in flash. Obj_A : constant Dcd_T := ( Next => Obj_B_Addr, ...); for Obj_A'Address use System.Storage_Elements.To_Address (Obj_A_Addr);