Representation clauses specify how the types of the language are to be mapped onto the underlying machine. They can be provided to give more efficient representation or to interface with features that are outside the domain of the language (for example, peripheral hardware).
representation_clause ::= type_representation_clause | address_clause type_representation_clause ::= length_clause | enumeration_representation_clause |record_representation_clause
A type representation clause applies either to a type or to a first named subtype (that is, to a subtype declared by a type declaration, the base type being therefore anonymous). Such a representation clause applies to all objects that have this type or this first named subtype. At most one enumeration or record representation clause is allowed for a given type: an enumeration representation clause is only allowed for an enumeration type; a record representation clause, only for a record type. (On the other hand, more than one length clause can be provided for a given type; moreover, both a length clause and an enumeration or record representation clause can be provided.) A length clause is the only form of representation clause allowed for a type derived from a parent type that has (user-defined) derivable subprograms.
An address clause applies either to an object; to a subprogram, package, or task unit; or to an entry. At most one address clause is allowed for any of these entities.
A representation clause and declaration of the entity to which the clause applies must both occur immediately within the same declarative part, package specification, or task specification; the declaration must occur before the clause. In the absence of a representation clause for a given declaration, a default representation of this declaration is determined by the implementation. Such a default determination occurs no later than the end of the immediately enclosing declarative part, package specification, or task specification. For a declaration given in a declarative part, this default determination occurs before any enclosed body.
In the case of a type, certain occurrences of its name imply that the representation of the type must already have been determined. Consequently these occurrences force the default determination of any aspect of the representation not already determined by a prior type representation clause. This default determination is also forced by similar occurrences of the name of a subtype of the type, or of the name of any type or subtype that has subcomponents of the type. A forcing occurence is any occurrence other than in a type or subtype declaration, a subprogram specification, an entry declaration, a deferred constant declaration, a pragma, or a representation clause for the type itself. In any case, an occurrence within an expression is always forcing.
A representation clause for a given entity must not appear after an occurrence of the name of the entity if this occurrence forces a default determination of representation for the entity.
Similar restrictions exist for address clauses. For an object, any occurrence of its name (after the object declaration) is a forcing occurrence. For a subprogram, package, task unit, or entry, any occurrence of a representation attribute of such an entity is a forcing occurrence.
The effect of the elaboration of a representation clause is to define the corresponding aspects of the representation.
The interpretation of some of the expressions that appear in representation clauses is implementation_dependent, for example, expressions specifying addresses. An implementation may limit its acceptance of representation clauses to those that can be handled simply by the underlying hardware. If a representation clause is accepted by an implementation, the compiler must guarantee that the net effect of the program is not changed by the presence of the clause, except for address clauses and for parts of the program that interrogate representation attributes. If a program contains a representation clause that is not accepted, the program is illegal. For each implementation, the allowed representation clauses, and the conventions used for implementation- dependent expressions, must be documented in Appendix F of the reference manual.
Whereas a representation clause is used to impose certain characteristics of the mapping of an entity onto the underlying machine, pragmas can be used to provide an implementation, with criteria for its selection of such a mapping. The pragma PACK specifies that storage minimization should be the main criterion when selecting the representation of a record or array type. Its form is as follows:
pragma PACK (type_simple_name);
Packing means that gaps between the storage areas allocated to consecutive components should be minimized. It need not, however, affect the mapping of each component onto storage. This mapping can itself be influenced by a pragma (or controlled by a representation clause) for the component or component type. The position of a PACK pragma, and the restrictions on the named type, are governed by the same rules as for a representation clause; in particular, the pragma must appear before any use of a representation attribute of the packed entity.
The pragma PACK is the only language-defied representation pragma. Additional representation pragmas may be provided by an implementation; these must be documented in Appendix F. (in contrast to representation clauses, a pragma that is not accepted by the implementation is ignored).
No representation clause is allowed for a generic formal type.
References: address clause, allow, body, component, declaration, declarative part, default expression, deferred constant declaration, derivable subprogram, derived type, entity, entry, enumeration representation clause, expression, generic formal type, illegal, length clause, must, name, object, occur immediately within, package, package specification, parent type, pragma, record representation clause, representation attribute, and 13.7.3, subcomponent, subprogram, subtype, subtype declaration, task specification, task unit, type, type declaration.
Rationale references: 15.1 The Separation Principle, 15.2 Types and Data Representation, 15.3 Multiple Representations and Change of Representation, 15.4 Presentation of the Data Representation Facility
Style Guide references: 7.6.1 Representation Clauses
Address any questions or comments to email@example.com.