Hi all,

I've been told that Ada array elements are not guaranteed to be
contiguous unless the 'Convention C' aspect is applied.

Is this correct ?

Regards.

Le 19/02/2023 à 14:34, Rod Kay a écrit :
> Hi all,
>
>    I've been told that Ada array elements are not guaranteed to be
> contiguous unless the 'Convention C' aspect is applied.
>
>    Is this correct ?

The strength of Ada is that it protects you from all implementation
details, thus allowing compilers to choose the most efficient
implementation. Therefore, the answer is yes.

(BTW: try to find a definition of "contiguous". At byte level? At word
level? What if the element does not fill a byte?)

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

On 2023-02-19 16:28, J-P. Rosen wrote:
> Le 19/02/2023 à 14:34, Rod Kay a écrit :
>> Hi all,
>>
>>     I've been told that Ada array elements are not guaranteed to be
>> contiguous unless the 'Convention C' aspect is applied.
>>
>>     Is this correct ?
>
> The strength of Ada is that it protects you from all implementation
> details, thus allowing compilers to choose the most efficient
> implementation. Therefore, the answer is yes.

I tried to find a rule on "contiguity" in the Ada 2022 RM, but failed.
Can you point to one? Perhaps this rule is a consequence of C standard
rules for arrays (pointer arithmetic), and the general idea that Ada
should allow Convention C for a type only if that type is really
compatible with the C compiler (in question).

For a constrained array type I would choose to specify the size of the
component type, and the size of the array type to be the length of the
array times the component size. That should (also) ensure that the
elements are stored contiguously (if the Ada compiler accepts this size
specification).

It seems (RM B.3(62.4/3)) that Ada compilers are not required to support
Convention C for unconstrained array types. RM B.3 (Interfacing with
C/C++) declares such types with the Pack aspect, but that may or may not
(AIUI) give a contiguous representation.

> (BTW: try to find a definition of "contiguous". At byte level? At word
> level? What if the element does not fill a byte?)

Indeed. But it seems to me that Arr'Size = Arr'Length * Comp'Size is the
meaning usually intended for programming purposes.

On 2023-02-19 15:59, Niklas Holsti wrote:
> On 2023-02-19 16:28, J-P. Rosen wrote:

>> (BTW: try to find a definition of "contiguous". At byte level? At word
>> level? What if the element does not fill a byte?)
>
> Indeed. But it seems to me that Arr'Size = Arr'Length * Comp'Size is the
> meaning usually intended for programming purposes.

Rather: the bit offset of an element is a linear function of its position.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Le 19/02/2023 à 15:59, Niklas Holsti a écrit :
>> (BTW: try to find a definition of "contiguous". At byte level? At word
>> level? What if the element does not fill a byte?)
>
>
> Indeed. But it seems to me that Arr'Size = Arr'Length * Comp'Size is the
> meaning usually intended for programming purposes.

Certainly not if Comp'Size is not an integer number of bytes.
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

On 2023-02-19 19:10, J-P. Rosen wrote:
> Le 19/02/2023 à 15:59, Niklas Holsti a écrit :
>>> (BTW: try to find a definition of "contiguous". At byte level? At
>>> word level? What if the element does not fill a byte?)
>>
>>
>> Indeed. But it seems to me that Arr'Size = Arr'Length * Comp'Size is
>> the meaning usually intended for programming purposes.
>
> Certainly not if Comp'Size is not an integer number of bytes.

I'm not so certain. By choosing various roundings-up of the component
size, you can choose between "bit-contiguous", "byte-contiguous", etc.

For example, bit-contiguous with 2-bit components:

type Comp is (A, B, C, D) with Size => 2;

type Arr is array (1 .. 10) of Comp
with Pack, Size => 10 * Comp'Size;

Nybble-contiguous with Comp'Size => 4, byte- (octet-) contiguous with
Comp'Size => 8, etc.

(However, I haven't checked that eg. GNAT does the "right thing" with
such Size clauses, just that it accepts them. It does require the Pack
aspect for the array type when Comp'Size is not a multiple of 8.)

On 2023-02-19 17:08, Dmitry A. Kazakov wrote:
> On 2023-02-19 15:59, Niklas Holsti wrote:
>> On 2023-02-19 16:28, J-P. Rosen wrote:
>
>>> (BTW: try to find a definition of "contiguous". At byte level?
>>> At word level? What if the element does not fill a byte?)
>>
>> Indeed. But it seems to me that Arr'Size = Arr'Length * Comp'Size
>> is the meaning usually intended for programming purposes.
>
> Rather: the bit offset of an element is a linear function of its
> position.

That is ordering by index, but not contiguity: there may still be gaps
between elements. However, I assume you meant that the slope of the
linear function equals the component size, and then it includes contiguity.

The relationship of index order to memory-location order is certainly an
aspect that should be considered when interfacing to C or HW.

Pet peeve: on more than one occasion I have been disappointed that Ada
representation clauses do not let me specify the index-order of packed
array elements in a word, relative to the bit-numbering order, and I
have had to fall back to using several scalar-type record components, c1
... c7 say, instead of one array-type component, c(1..7).

On 2023-02-19 18:54, Niklas Holsti wrote:
> On 2023-02-19 17:08, Dmitry A. Kazakov wrote:

>> Rather: the bit offset of an element is a linear function of its
>> position.
>
> That is ordering by index, but not contiguity: there may still be gaps
> between elements. However, I assume you meant that the slope of the
> linear function equals the component size, and then it includes contiguity.

No gaps = packed = the most dense representation.

Contiguity is rather that the gaps are regular and can be considered a
part of each element. E.g. a video buffer with strides is not contiguous.

> The relationship of index order to memory-location order is certainly an
> aspect that should be considered when interfacing to C or HW.

An definition of contiguous array equivalent to linearity is that the
array body representation is isomorphic to slicing.

> Pet peeve: on more than one occasion I have been disappointed that Ada
> representation clauses do not let me specify the index-order of packed
> array elements in a word, relative to the bit-numbering order, and I
> have had to fall back to using several scalar-type record components, c1
> .. c7 say, instead of one array-type component, c(1..7).

This is as blasphemous as asking for n-D slices... (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2023-02-19 14:34, Rod Kay wrote:
>
>    I've been told that Ada array elements are not guaranteed to be contiguous
> unless the 'Convention C' aspect is applied.

The ARM says little about how the compiler represents objects in the absence of
representation clauses. However, ARM 13.7(12)
(http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-13-7-1.html#I5653) says,
"Storage_Array represents a contiguous sequence of storage elements."

ARM 13.9(17/3)
(http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-13-9.html#I5679) says
that a compiler that supports Unchecked_Conversion should use a contiguous
representation for certain constrained array subtypes.

Using convention Fortran should also ensure a contiguous representation, add can
apply (unlike convention C) to multidimensional arrays.

--
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Le 19/02/2023 à 18:54, Niklas Holsti a écrit :
> On 2023-02-19 19:10, J-P. Rosen wrote:
>> Le 19/02/2023 à 15:59, Niklas Holsti a écrit :
>>> Indeed. But it seems to me that Arr'Size = Arr'Length * Comp'Size is
>>> the meaning usually intended for programming purposes.
>>
>> Certainly not if Comp'Size is not an integer number of bytes.
>
> I'm not so certain. By choosing various roundings-up of the component
> size, you can choose between "bit-contiguous", "byte-contiguous", etc.
>
> For example, bit-contiguous with 2-bit components:
>
>    type Comp is (A, B, C, D) with Size => 2;
>
>    type Arr is array (1 .. 10) of Comp
>       with Pack, Size => 10 * Comp'Size;
>
> Nybble-contiguous with Comp'Size => 4, byte- (octet-) contiguous with
> Comp'Size => 8, etc.
>
Of course, if you add representation clauses, the compiler will obey
them. But the OP's question was whether it was /guaranteed/ to have
contiguous representation, and the answer is no - for good reasons.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

Thank you all for the replies.

To summarise then, contiguity is not guaranteed unless the array is of
convention C, convention Fortran or representation clauses are applied.

Regards.