2.8. Section 13: Representation Issues

The information in this section relates to Annex M paragraphs 43 to 59.

Q: M.(43)
Q: M.(44)
Q: M.(45)
Q: M.(46)
Q: M.(47)
Q: M.(48)
Q: M.(49)
Q: M.(50)
Q: M.(51)
Q: M.(52)
Q: M.(53)
Q: M.(54)
Q: M.(55)
Q: M.(56)
Q: M.(57)
Q: M.(58)
Q: M.(59)

Q: M.(43)

The interpretation of each aspect of representation. See 13.1(20).

A: See separate section on data representations.

Q: M.(44)

Any restrictions placed upon representation items. See 13.1(20).

A: See separate section on data representations.

Q: M.(45)

The meaning of Size for indefinite subtypes. See 13.3(48).

A: Size for an indefinite subtype is the maximum possible size, except that for the case of a subprogram parameter, the size of the parameter object is the actual size.

Q: M.(46)

The default external representation for a type tag. See 13.3(75).

A: This feature is not supported.

Q: M.(47)

What determines whether a compilation unit is the same in two different partitions. See 13.3(76).

A: A compilation unit is the same in two different partitions if and only if it derives from the same source file.

Q: M.(48)

Implementation-defined components. See 13.5.1(15).

A: The only implementation defined component is the tag for a tagged type, which contains a pointer to the dispatching table.

Q: M.(49)

If Word_Size = Storage_Unit, the default bit ordering. See 13.5.3(5).

A: Word_Size (32) is not the same as Storage_Unit (8) for this implementation, so no non-default bit ordering is supported. The default bit ordering corresponds to the natural endianness of the target architecture.

Q: M.(50)

The contents of the visible part of package System and its language-defined children. See 13.7(2).

A: See the definition of these packages in files system.ads and s-stoele.ads.

Q: M.(51)

The contents of the visible part of package System.Machine_Code, and the meaning of code_statements. See 13.8(7).

A: See the definition and documentation in file s-maccod.ads.

Q: M.(52)

The effect of unchecked conversion. See 13.9(11).

A: Unchecked conversion between types of the same size and results in an uninterpreted transmission of the bits from one type to the other. If the types are of unequal sizes, then in the case of discrete types, a shorter source is first zero or sign extended as necessary, and a shorter target is simply truncated on the left. For all non-discrete types, the source is first copied if necessary to ensure that the alignment requirements of the target are met, then a pointer is constructed to the source value, and the result is obtained by dereferencing this pointer after converting it to be a pointer to the target type.

Q: M.(53)

The manner of choosing a storage pool for an access type when Storage_Pool is not specified for the type. See 13.11(17).

A: There are 3 different standard pools used by the compiler when Storage_Pool is not specified depending whether the type is local to a subprogram or defined at the library level and whether Storage_Sizeis specified or not. See documentation in the runtime library units System.Pool_Global, System.Pool_Size and System.Pool_Local in files s-poosiz.ads, s-pooglo.ads and s-pooloc.ads for full details on the default pools used.

Q: M.(54)

Whether or not the implementation provides user-accessible names for the standard pool type(s).

A: See 13.11(17).

See documentation in the sources of the run time mentioned in paragraph M.(53). All these pools are accessible by means of with'ing these units.

Q: M.(55)

The meaning of Storage_Size. See 13.11(18).

A: Storage_Size is measured in storage units, and refers to the total space available for an access type collection, or to the primary stack space for a task.

Q: M.(56)

Implementation-defined aspects of storage pools. See 13.11(22).

A: See documentation in the sources of the run time mentioned in paragraph M.(53) for details on ERC32 Ada-defined aspects of storage pools.

Q: M.(57)

The set of restrictions allowed in a pragma Restrictions. See 13.12(7).

A: All RM defined Restriction identifiers are implemented. The following additional restriction identifiers are provided:

No_Implementation_Attributes

This restriction checks at compile time that no ERC32 Ada-defined attributes are present. With this restriction, the only attributes that can be used are those defined in the Ada 95 Reference Manual.

No_Implementation_Pragmas

This restriction checks at compile time that no ERC32 Ada-defined pragmas are present. With this restriction, the only pragmas that can be used are those defined in the Ada 95 Reference Manual.

No_Elaboration_Code

This restriction ensures at compile time that no elaboration code is generated. Note that this is not the same condition as is enforced by pragma Preelaborate. There are cases in which pragma Preelaborate still permits code to be generated (e.g. code to initialize a large array to all zeroes), and there are cases of units which do not meet the requirements for pragma Preelaborate, but for which no elaboration code is generated. Generally, it is the case that preelaborable units will meet the restrictions, with the exception of large aggregates initialized by others.

Q: M.(58)

The consequences of violating limitations on Restrictions pragmas. See 13.12(9).

A: Restrictions that can be checked at compile time result in illegalities if violated. Currently there are no other consequences of violating restrictions.

Q: M.(59)

The representation used by the Read and Write attributes of elementary types in terms of stream elements. See 13.13.2(9).

A: The representation is the in-memory representation of the base type of the type, using the number of bits corresponding to the type'Size value, and the natural ordering of the machine.