Contents Index Search Previous Next
13.5.1 Record Representation Clauses
specifies the storage representation of records and record extensions,
that is, the order, position, and size of components (including discriminants,
for first_subtype_local_name use
component_local_name at position range first_bit
Name Resolution Rules
is expected to be of
any integer type.
of a record_representation_clause
shall denote a specific nonlimited record or record extension subtype.
If the component_local_name
is a direct_name, the local_name
shall denote a component of the type. For a record extension, the component
shall not be inherited, and shall not be a discriminant that corresponds
to a discriminant of the parent type. If the component_local_name
has an attribute_designator, the
direct_name of the local_name
shall denote either the declaration of the type or a component of the
type, and the attribute_designator
shall denote an implementation-defined implicit component of the type.
first_bit, and last_bit
shall be static expressions. The value of position
and first_bit shall be nonnegative.
The value of last_bit shall be no
less than first_bit - 1.
At most one component_clause
is allowed for each component of the type, including for each discriminant
(component_clauses may be given
for some, all, or none of the components). Storage places within a component_list
shall not overlap, unless they are for components in distinct variants
of the same variant_part.
A name that denotes a component of a type is
not allowed within a record_representation_clause
for the type, except as the component_local_name
of a component_clause.
(without the mod_clause
the layout. The storage place attributes (see 13.5.2
are taken from the values of the position
, and last_bit
expressions after normalizing those values so that first_bit
is less than Storage_Unit.
for a record extension does not override the layout of the parent part;
if the layout was specified for the parent type, it is inherited by the
An implementation may generate implementation-defined
components (for example, one containing the offset of another component).
An implementation may generate names that denote such implementation-defined
components; such names shall be implementation-defined attribute_references.
An implementation may allow such implementation-defined names to be used
An implementation can restrict such component_clauses
in any manner it sees fit.
If a record_representation_clause
is given for an untagged derived type, the storage place attributes for
all of the components of the derived type may differ from those of the
corresponding components of the parent type, even for components whose
storage place is not specified explicitly in the record_representation_clause.
recommended level of support for record_representation_clause
- 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 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.
- 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.
- An implementation may reserve a storage
place for the tag field of a tagged type, and disallow other components
from overlapping that place.
- 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.
12 If no component_clause
is given for a component, then the choice of the storage place for the
component is left to the implementation. If component_clauses
are given for all components, the record_representation_clause
completely specifies the representation of the type and will be obeyed
exactly by the implementation.
Example of specifying
the layout of a record type:
Word : constant := 4; -- storage element is byte, 4 bytes per word
type State is (A,M,W,P);
type Mode is (Fix, Dec, Exp, Signif);
type Byte_Mask is array (0..7) of Boolean;
type State_Mask is array (State) of Boolean;
type Mode_Mask is array (Mode) of Boolean;
type Program_Status_Word is
System_Mask : Byte_Mask;
Protection_Key : Integer range 0 .. 3;
Machine_State : State_Mask;
Interrupt_Cause : Interruption_Code;
Ilc : Integer range 0 .. 3;
Cc : Integer range 0 .. 3;
Program_Mask : Mode_Mask;
Inst_Address : Address;
for Program_Status_Word use
System_Mask at 0*Word range 0 .. 7;
Protection_Key at 0*Word range 10 .. 11; -- bits 8,9 unused
Machine_State at 0*Word range 12 .. 15;
Interrupt_Cause at 0*Word range 16 .. 31;
Ilc at 1*Word range 0 .. 1; -- second word
Cc at 1*Word range 2 .. 3;
Program_Mask at 1*Word range 4 .. 7;
Inst_Address at 1*Word range 8 .. 31;
for Program_Status_Word'Size use 8*System.Storage_Unit;
for Program_Status_Word'Alignment use 8;
13 Note on the example:
defines the record layout. The Size clause guarantees that (at least)
eight storage elements are used for objects of the type. The Alignment
clause guarantees that aliased, imported, or exported objects of the
type will have addresses divisible by eight.
Contents Index Search Previous Next Legal