Section 13: Representation Issues 13.1 Representation Items
13.3 Representation Attributes Insert after paragraph 8: [AI95-00133-01]
A storage element is an addressable element of storage in the machine. A word is the largest amount of storage that can be conveniently and efficiently manipulated by the hardware, given the implementation's run-time model. A word consists of an integral number of storage elements.
the new paragraph:
A machine scalar is an amount of storage that can be conveniently and efficiently loaded, stored, or operated upon by the hardware. Machine scalars consist of an integral number of storage elements. The set of
machine scalars is implementation defined, but must include at least the storage element and the word. Machine scalars are used to interpret component_clauses when the nondefault bit ordering applies.
Replace paragraph 25: [AI95-00051-01]
Alignment may be specified for first subtypes and stand-alone objects via an
attribute_definition_clause; the expression of such a clause shall be static, and its value nonnegative. If the Alignment of a subtype is specified, then the Alignment of an object of the subtype is at least as strict, unless the object's Alignment is also specified. The Alignment of an object created by an allocator is that of the designated subtype.
by:
Alignment may be specified for first subtypes and stand-alone objects via an
attribute_definition_clause; the expression of such a clause shall be static, and its value
nonnegative. The Alignment of an object is at least as strict as the Alignment of its subtype, unless the object's Alignment is specified. The Alignment of an object created by an allocator is that of the designated subtype.
Delete paragraph 26: [AI95-00247-01]
If an Alignment is specified for a composite subtype or object, this Alignment shall be equal to the least common multiple of any specified Alignments of the subcomponent subtypes, or an integer multiple thereof.
Replace paragraph 28: [AI95-00051-01]
If the Alignment is specified for an object that is not allocated under control of the implementation, execution is erroneous if the object is not aligned according to the Alignment.
by:
Program execution is erroneous if an object that is not allocated under control of the implementation is not aligned according to its Alignment.
Replace paragraph 30: [AI95-00051-01]
• An implementation should support specified Alignments that are factors and multiples of the number of storage elements per word, subject to the following:
by:
• An implementation should support a confirming Alignment clause for any kind of type.
• An implementation should support a nonconfirming Alignment clause for a discrete type, fixed point type, record type, or array type, specifying an Alignment value that is zero or a power of two, subject to the following:
Replace paragraph 31: [AI95-00051-01]
• An implementation need not support specified Alignments for combinations of Sizes and Alignments that cannot be easily loaded and stored by available machine instructions. by:
• An implementation need not support an Alignment clause for a signed integer type specifying an Alignment greater than the largest Alignment value that is ever chosen by default by the
implementation for any signed integer type. A corresponding limitation may be imposed for modular integer types, fixed point types, enumeration types, record types, and array types.
Replace paragraph 32: [AI95-00051-01]
• An implementation need not support specified Alignments that are greater than the maximum Alignment the implementation ever returns by default.
by:
• An implementation need not support a nonconfirming Alignment clause which could enable the creation of an object of an elementary type which cannot be easily loaded and stored by available machine instructions.
Replace paragraph 42: [AI95-00051-01]
The recommended level of support for the Size attribute of objects is: by:
The recommended level of support for the Size attribute of objects is the same as for subtypes (see below).
Delete paragraph 43: [AI95-00051-01]
• 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).
Replace paragraph 50: [AI95-00051-01]
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: by:
If the Size of a subtype 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:
Insert after paragraph 56: [AI95-00051-01]
• 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.
the new paragraphs:
• An implementation should support a confirming Size clause for any kind of type.
• An implementation should support a nonconfirming Size clause for a discrete type or a fixed point type, subject to the following:
• An implementation need not support a Size clause for a signed integer type specifying a Size greater than that of the largest signed integer type supported by the implementation in the absence of a size clause (that is, when the size is chosen by default). A corresponding limitation may be imposed for modular integer types, fixed point types, and enumeration types.
13.5.1 Record Representation Clauses
Insert after paragraph 10: [AI95-00133-01]The position, 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.
the new paragraphs:
If the nondefault bit ordering applies to the type, then either:
• the value of last_bit shall be less than the size of the largest machine scalar; or
• the value of first_bit shall be zero and the value of last_bit + 1 shall be a multiple of System.Storage_Unit.
Replace paragraph 13: [AI95-00133-01]
A record_representation_clause (without the mod_clause) specifies the layout. The storage place attributes (see 13.5.2) are taken from the values of the position, first_bit, and last_bit expressions after normalizing those values so that first_bit is less than Storage_Unit.
by:
A record_representation_clause (without the mod_clause) specifies the layout. If the default bit ordering applies to the type, the position, first_bit, and last_bit of each component_clause directly specify the position and size of the corresponding component. If the nondefault bit ordering applies to the type then the layout is determined as follows:
• the component_clauses for which the value of last_bit is greater than or equal to the size of the largest machine scalar directly specify the position and size of the corresponding component;
• for other component_clauses, all the components having the same value of position are
considered to be part of a single machine scalar, located at that position; this machine scalar has a size which is the smallest machine scalar size larger than the largest last_bit for all
component_clauses at that position; the first_bit and last_bit of each component_clause are then interpreted as bit offsets in this machine scalar.
Insert after paragraph 17: [AI95-00133-01]
The recommended level of support for record_representation_clauses is: the new paragraph:
• An implementation should support machine scalars that correspond to all the integer, floating point, and address formats supported by the machine.
13.5.2 Storage Place Attributes
Replace paragraph 2: [AI95-00133-01]R.C'Position
Denotes the same value as R.C'Address - R'Address. The value of this attribute is of the type universal_integer.
by:
R.C'Position
If the nondefault bit ordering applies to the composite type, and if a component_clause specifies the placement of C, denotes the value given for the position of the component_clause; otherwise, denotes the same value as R.C'Address - R'Address. The value of this attribute is of the type universal_integer.
Replace paragraph 3: [AI95-00133-01] R.C'First_Bit
Denotes the offset, from the start of the first of the storage elements occupied by C, of the first bit occupied by C. This offset is measured in bits. The first bit of a storage element is numbered zero. The value of this attribute is of the type universal_integer.
by:
R.C'First_Bit
If the nondefault bit ordering applies to the composite type, and if a component_clause specifies the placement of C, denotes the value given for the first_bit of the component_clause; otherwise, denotes the offset, from the start of the first of the storage elements occupied by C, of the first bit occupied by C. This offset is measured in bits. The first bit of a storage element is numbered zero. The value of this attribute is of the type universal_integer.
Replace paragraph 4: [AI95-00133-01] R.C'Last_Bit
Denotes the offset, from the start of the first of the storage elements occupied by C, of the last bit occupied by C. This offset is measured in bits. The value of this attribute is of the type
universal_integer. by:
R.C'Last_Bit
If the nondefault bit ordering applies to the composite type, and if a component_clause specifies the placement of C, denotes the value given for the last_bit of the component_clause; otherwise, denotes the offset, from the start of the first of the storage elements occupied by C, of the last bit occupied by C. This offset is measured in bits. The value of this attribute is of the type
universal_integer.
13.5.3 Bit Ordering
Replace paragraph 8: [AI95-00133-01]
• If Word_Size = Storage_Unit, then the implementation should support the nondefault bit ordering in addition to the default bit ordering.
by:
• The implementation should support the nondefault bit ordering in addition to the default bit ordering.
13 Bit_Order clauses make it possible to write record_representation_clauses that can be ported between machines having different bit ordering. They do not guarantee transparent exchange of data between such machines.