From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b657b1c99e7e7039 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: bit numbers in packed arrays of Boolean Date: Tue, 31 Aug 2010 17:30:28 +0300 Organization: Tidorum Ltd Message-ID: <8e4i04FagkU1@mid.individual.net> References: <82r5hfghjr.fsf@stephe-leake.org> <8e4b6rF1dlU1@mid.individual.net> <108mw0hcfwlnl.1klsp2e3omofa.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net kwV5ED9J6ZsENITToi/wXwonjYLNyaMUCtAzAVkxEQHb13xgwV Cancel-Lock: sha1:I/6WnEt/nbfK3ZNXe81ca2zepXA= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: Xref: g2news1.google.com comp.lang.ada:13878 Date: 2010-08-31T17:30:28+03:00 List-Id: Yannick Duchêne (Hibou57) wrote: > Le Tue, 31 Aug 2010 15:08:02 +0200, Dmitry A. Kazakov > a écrit: >> The representation = memory pattern. When RM says that S and T have same >> representation that is merely same pattern. It tells nothing about >> ordering of bits. Any combination of 8-bits is same representation of >> Unsigned_8 and Boolean array (1..8). > If I understand correctly, this suggests bits representation should be > accessed (read/write) all the same way, whatever the type it implements. I'm not sure what you mean, but for me the *type* used to access a memory location is the factor that determines what the bits, and each bit, represents. The correspondence between bits in Unsigned_8 and a packed array of 8 Booleans is entirely implementation-defined, but can be inspected by Unchecked_Conversion between the types. I'm not sure if the standard even requires, for a packed array of 8 Booleans of Size 8 bits, that each one of those bits should represent exactly one of the Boolean components. But even if one component is represented in one bit, the encoding (whether 0 is False and 1 is True, or vice versa) is implementation-defined (and could, I believe, be different depending on the index of the component... although that would be weird). > I still feel this is implementation defined and I would not rely on it > (or else I missed something). I think Dmitry and I agree, with you, that it is implementation-defined. > A tricky and imaginary example by the way: imagine a clever compiler > with clever optimization, which would detect the application mostly > access the nth item of the array and far less oftenly access any other > items, now let say the target CPU has a special instruction to access > bit value at #0 (common practice on CISC processor), then it could > choose to map this nth item on bit #0. > > Do you feel the language would disallow such an optimization ? No. I think that the basic RM does not say anything about the order of components in an array, whether Packed or not. (See below for Annexes.) > Side note: a compiler could do something similar for an unpacked array > as well ; it could move the nth item at offset 0, to save processing of > an offset while accessing an element which was determined as far more > frequently accessed than the others. > > Seems possible ? In principle, yes. Pragma Convention C or Fortran should impose some ordering rules, from the C/Fortran rules, and perhaps something is also implied by the Implementation Advice on the Ada/C interface in RM B.3(62.1/2 through 75). For example, the rule RM B.3(70) says that an Ada "array (..) of T" should be passed to C as "*t", where t is the C type corresponding to the Ada type T. For this to be a useful rule, the components in the Ada array must be laid out as in the C case, that is, with the address increasing monotonically with the index. Which is, of course, the natural lay-out that one would expect, in any case. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .