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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)