Re: bit numbers in packed arrays of Boolean

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

Yannick Duchêne (Hibou57) wrote:
> Le Tue, 31 Aug 2010 15:08:02 +0200, Dmitry A. Kazakov 
> <mailbox@dmitry-kazakov.de> 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
       .      @       .