Q: 13.1 (21-24): Representation Clauses
The recommended level of support for all representation items is qualified as follows:
An implementation need not support representation items containing non-static expressions, except that an implementation should support a representation item for a given entity if each non-static expression in the representation item is a name that statically denotes a constant declared before the entity.
A: Followed. XGC Ada does not support non-static expressions in representation clauses unless they are constants declared before the entity.
An implementation need not support a specification for the Size for a given composite subtype, nor the size or storage place for an object (including a component) of a given composite subtype, unless the constraints on the subtype and its composite subcomponents (if any) are all static constraints.
A: Followed. Size Clauses are not permitted on non-static components, as described above.
An aliased component, or a component whose type is by-reference, should always be allocated at an addressable location.
A: Followed.
If a type is packed, then the implementation should try to minimize storage allocated to objects of the type, possibly at the expense of speed of accessing components, subject to reasonable complexity in addressing calculations.
The recommended level of support pragma Pack is:
For a packed record type, the components should be packed as tightly as possible subject to the Sizes of the component subtypes, and subject to any record_representation_clause that applies to the type; the implementation may, but need not, reorder components or cross aligned word boundaries to improve the packing. A component whose Size is greater than the word size may be allocated an integral number of words.
A: Partly followed. Tight packing of arrays is supported for component sizes of 1, 2, 4, 8, 16 and 32 bits.
A: Followed.
Q: 13.3(14-19): Address Clauses
For an array X, X'Address should point at the first component of the array, and not at the array bounds.
A: Followed.
The recommended level of support for the Address attribute is:
X'Address should produce a useful result if X is an object that is aliased or of a by-reference type, or is an entity whose Address has been specified.
Followed. A valid address will be produced even if none of those conditions have been met. If necessary, the object is forced into memory to ensure the address is valid.
A: Followed.
Objects (including subcomponents) that are aliased or of a by-reference type should be allocated on storage element boundaries.
A: Followed.
If the Address of an object is specified, or it is imported or exported, then the implementation should not perform optimizations based on assumptions of no aliases.
A: Followed.
Q: 13.3(29-35): Alignment Clauses
The recommended level of support for the Alignment attribute for subtypes is:
An implementation should support specified Alignments that are factors and multiples of the number of storage elements per word, subject to the following:
A: Followed.
An implementation need not support specified Alignments for combinations of Sizes and Alignments that cannot be easily loaded and stored by available machine instructions.
A: Followed.
An implementation need not support specified Alignments that are greater than the maximum Alignment the implementation ever returns by default.
A: Followed.
The recommended level of support for the Alignment attribute for objects is:
For stand-alone library-level objects of statically constrained subtypes, the implementation should support all Alignments supported by the target linker. For example, page alignment is likely to be supported for such objects, but not for subtypes.
A: Followed.
The recommended level of support for the Size attribute of objects is:
A Size clause should be supported for an object if the specified Size is at least as large as its subtype's Size, and corresponds to a size in storage elements that is a multiple of the object's Alignment (if the Alignment is nonzero).
A: Followed.
If the Size of a subtype is specified, and allows for efficient independent addressability (see 9.10) on the target architecture, then the Size of the following objects of the subtype should equal the Size of the subtype:
Aliased objects (including components).
A: Followed.
Size clause on a composite subtype should not affect the internal layout of components.
A: Followed.
The recommended level of support for the Size attribute of subtypes is:
The Size (if not specified) of a static discrete or fixed point subtype should be the number of bits needed to represent each value belonging to the subtype using an unbiased representation, leaving space for a sign bit only if the subtype contains negative values. If such a subtype is a first subtype, then an implementation should support a specified Size for it that reflects this representation.
A: Followed.
For a subtype implemented with levels of indirection, the Size should include the size of the pointers, but not the size of what they point at.
A: Followed.
Q: 13.3(71-73): Component Size Clauses
The recommended level of support for the Component_Size attribute is:
An implementation need not support specified Component_Sizes that are less than the Size of the component subtype.
A: Followed.
An implementation should support specified Component_Sizes that are factors and multiples of the word size. For such Component_Sizes, the array should contain no gaps between components. For other Component_Sizes (if supported), the array should contain no gaps between components when packing is also specified; the implementation should forbid this combination in cases where it cannot support a no-gaps representation.
A: Followed.
Q: 13.4(9-10): Enumeration Representation Clauses
The recommended level of support for enumeration representation clauses is:
An implementation need not support enumeration representation clauses for boolean types, but should at minimum support the internal codes in the range System.Min_Int.System.Max_Int.
A: Followed.
Q: 13.5.1(17-22): Record Representation Clauses
The recommended level of support for record_representation_clauses is:
An implementation should support storage places that can be extracted with a load, mask, shift sequence of machine code, and set with a load, shift, mask, store sequence, given the available machine instructions and run-time model.
A: Followed.
A storage place should be supported if its size is equal to the Size of the component subtype, and it starts and ends on a boundary that obeys the Alignment of the component subtype.
A: Followed.
If the default bit ordering applies to the declaration of a given type, then for a component whose subtype's Size is less than the word size, any storage place that does not cross an aligned word boundary should be supported.
A: Followed.
An implementation may reserve a storage place for the tag field of a tagged type, and disallow other components from overlapping that place.
A: Followed.
An implementation need not support a component_clause for a component of an extension part if the storage place is not after the storage places of all components of the parent type, whether or not those storage places had been specified.
A: Followed. The above advice on record representation clauses is followed, and all mentioned features are implemented.
Q: 13.5.2(5): Storage Place Attributes
If a component is represented using some form of pointer (such as an offset) to the actual data of the component, and this data is contiguous with the rest of the object, then the storage place attributes should reflect the place of the actual data, not the pointer. If a component is allocated discontinuously from the rest of the object, then a warning should be generated upon reference to one of its storage place attributes.
A: Followed. There are no such components in XGC Ada.
The recommended level of support for the non-default bit ordering is:
If Word_Size = Storage_Unit, then the implementation should support the non-default bit ordering in addition to the default bit ordering.
A: Followed. Word size does not equal storage size in this implementation. Thus non-default bit ordering is not supported.
A: Not Followed. The type Address is visible.
Q: 13.7.1(16): Address Operations
Operations in System and its children should reflect the target environment semantics as closely as is reasonable. For example, on most machines, it makes sense for address arithmetic to wrap around. Operations that do not make sense should raise Program_Error.
A: Followed. Address arithmetic is modular arithmetic that wraps around. No operation raises Program_Error, since all operations make sense.
Q: 13.9(14-17): Unchecked Conversion
The Size of an array object should not include its bounds; hence, the bounds should not be part of the converted data.
A: Followed.
The implementation should not generate unnecessary run-time checks to ensure that the representation of S is a representation of the target type. It should take advantage of the permission to return by reference when possible. Restrictions on unchecked conversions should be avoided unless required by the target environment.
A: Followed. There are no restrictions on unchecked conversion. A warning is generated if the source and target types do not have the same size since the semantics in this case may be target dependent.
The recommended level of support for unchecked conversions is:
Unchecked conversions should be supported and should be reversible in the cases where this clause defines the result. To enable meaningful use of unchecked conversion, a contiguous representation should be used for elementary subtypes, for statically constrained array subtypes whose component subtype is one of the subtypes described in this paragraph, and for record subtypes without discriminants whose component subtypes are described in this paragraph.
A: Followed.
Q: 13.11(23-25): Implicit Heap Usage
An implementation should document any cases in which it dynamically allocates heap storage for a purpose other than the evaluation of an allocator.
A: Followed, the only other points at which heap storage is dynamically allocated are as follows:
To allocate space for a task when a task is created.
A default (implementation-provided) storage pool for an access-to- constant type should not have overhead to support de-allocation of individual objects.
A: Not applicable.
A storage pool for an anonymous access type should be created at the point of an allocator for the type, and be reclaimed when the designated object becomes inaccessible.
A: Followed.
Q: 13.11.2(17): Unchecked De-allocation
For a standard storage pool, Free should actually reclaim the storage.
A: Not supported.
Q: 13.13.2(17): Stream Oriented Attributes
If a stream element is the same size as a storage element, then the normal in-memory representation should be used by Read and Write for scalar objects. Otherwise, Read and Write should use the smallest number of stream elements needed to represent all values in the base range of the scalar type.
A: Not supported.