CVS difference for ais/ai-00133.txt

Differences between 1.12 and version 1.13
Log of other versions for file ais/ai-00133.txt

--- ais/ai-00133.txt	2004/09/04 01:13:42	1.12
+++ ais/ai-00133.txt	2004/10/05 22:48:59	1.13
@@ -1,5 +1,14 @@
-!standard 13.05.03 (00)                               04-08-27  AI95-00133/04
+!standard 13.05.03 (08)                               04-09-28  AI95-00133/05
+!standard 13.03 (08)
+!standard 13.05.01 (10)
+!standard 13.05.01 (13)
+!standard 13.05.01 (17)
+!standard 13.05.02 (02)
+!standard 13.05.02 (03)
+!standard 13.05.02 (04)
 !class binding interpretation 96-05-07
+!status Amendment 200Y 04-09-27
+!status ARG Approved 8-0-1  04-09-18
 !status work item 96-05-07
 !status received 96-05-07
 !priority Medium
@@ -12,7 +21,7 @@
 *machine scalars*, which are chunks of storage that can be natively loaded and
 stored by the machine. All the component_clauses at a given offset are
 considered to be part of the same machine scalar, and the first_bit and last_bit
-are interpreted are bit offsets within that machine scalar. This makes it
+are interpreted as bit offsets within that machine scalar. This makes it
 possible to write endian-independent record_representation_clauses.
 
 The recommended level of support for Bit_Order clauses is modified to include
@@ -21,7 +30,7 @@
 !question
 
 What problem is the Bit_Order attribute supposed to solve?
-Is is intended to solve:
+Is it intended to solve:
    1) the "compiler uniformity problem" where a single program on
       a single processor wishes to use unchecked_conversion to
       convert a scalar (e.g. float) object to a record type (e.g.
@@ -51,36 +60,47 @@
 word. [Machine scalars are used to interpret component_clauses when the
 nondefault bit ordering applies.]
 
-[Author's Note: At the Palma meeting I was asked to remove the notion of
-machine scalar because "this is about the size of a scalar, not the item
-itself". Well, that's not true, we speak of the machine scalars as containers
-all over this AI, so I didn't change anything. I have no problem with replacing
-"machine scalar" with "thingamabob" but I believe that we need the concept.
-Note that it was in Norm's original paper, and Norm rarely gets things wrong.]
+The set of machine scalars is implementation defined.
 
 
 Add after 13.5.1(10)
 
-If the nondefault bit ordering applies to the type, the value of last_bit shall
-be less than the size of the largest machine scalar.
+If the nondefault bit ordering applies to the type, then either:
 
+o   the value of last_bit shall be less than the size of the largest machine
+scalar; or
 
+o   the value of first_bit shall be zero and the value of last_bit + 1 shall be
+a multiple of System.Storage_Unit.
+
+
 Replace 13.5.1(13) by:
 
 A record_representation_clause (without the mod_clause) specifies the layout.
 
-If the nondefault bit ordering applies to the type, all the components having a
-component_clause specifying a given position are considered to be part of a
-single machine scalar, located at that position. The size of this machine scalar
-is determined by rounding up the largest value specified for last_bit. The
-first_bit and last_bit of each component_clause are then interpreted as bit
-offsets in this machine scalar.
+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:
+
+o   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;
+
+o   for the 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.
 
 
 Add after 13.5.1(17):
 
 o  An implementation should support machine scalars that correspond to all the
-integer, floating-point and address formats supported by the machine.
+integer, floating point, and address formats supported by the machine.
 
 
 Replace 13.5.2(2-4) by:
@@ -95,7 +115,7 @@
 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 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
@@ -104,7 +124,7 @@
 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 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.
@@ -287,6 +307,146 @@
 the same bit as bit b of byte a+1. However, the existing RM is sufficiently
 vague and muddled that it's hard to believe that there is a lot of code out
 there depending on record_representation_clauses with nondefault bit ordering.
+
+
+!corrigendum 13.3(8)
+
+@dinsa
+A @i<storage element> is an addressable element of storage in the machine. A
+@i<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.
+@dinst
+A @i<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-dependent, 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. The set of machine scalars is implementation
+defined.
+
+
+!corrigendum 13.5.1(10)
+
+@dinsa
+The @fa<position>, @fa<first_bit>, and @fa<last_bit> shall be static
+expressions. The value of @fa<position> and @fa<first_bit> shall be
+nonnegative. The value of @fa<last_bit> shall be no less than @fa<first_bit> - 1.
+@dinss
+If the nondefault bit ordering applies to the type, then either:
+
+@xbullet<the value of @fa<last_bit> shall be less than the size of the largest
+machine scalar; or>
+@xbullet<the value of @fa<first_bit> shall be zero and the value of
+@fa<last_bit> + 1 shall be a multiple of System.Storage_Unit.>
+
+!corrigendum 13.5.1(13)
+
+@drepl
+A @fa<record_representation_clause> (without the @fa<mod_clause>) specifies the
+layout. The storage place attributes (see 13.5.2) are taken from the values of
+the @fa<position>, @fa<first_bit>, and @fa<last_bit> expressions after
+normalizing those values so that first_bit is less than Storage_Unit.
+@dby
+A @fa<record_representation_clause> (without the @fa<mod_clause>) specifies the
+layout.
+
+If the default bit ordering applies to the type, the @fa<position>,
+@fa<first_bit> and @fa<last_bit> of each @fa<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:
+
+@xbullet<the @fa<component_clause>s for which the value of @fa<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;>
+
+@xbullet<for the other @fa<component_clause>s, all the components having the
+same value of @fa<position> are considered to be part of a single machine
+scalar, located at that @fa<position>; this machine scalar has a size which is
+the smallest machine scalar size larger than the largest @fa<last_bit> for all
+@fa<component_clause>s at that @fa<position>; the @fa<first_bit> and
+@fa<last_bit> of each @fa<component_clause> are then interpreted as bit offsets
+in this machine scalar.>
+
+
+!corrigendum 13.5.1(17)
+
+@dinsa
+The recommended level of support for @fa<record_representation_clause>s is:
+@dinst
+@xbullet<An implementation should support machine scalars that correspond to
+all the integer, floating point, and address formats supported by the machine.>
+
+
+!corrigendum 13.5.2(02)
+
+@drepl
+@xhang<@xterm<R.C'Position>
+Denotes the same value as R.C'Address - R'Address. The value of this attribute
+is of the type @i<universal_integer>.>
+@dby
+@xhang<@xterm<R.C'Position>
+If the nondefault bit ordering applies to the composite type, and if a
+@fa<component_clause> specifies the placement of C, denotes the value given for
+the @fa<position> of the @fa<component_clause>; otherwise, denotes the same
+value as R.C'Address - R'Address.  The value of this attribute is of the type
+@i<universal_integer>.>
+
+!corrigendum 13.5.2(03)
+
+@drepl
+@xhang<@xterm<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 @i<universal_integer>.>
+@dby
+@xhang<@xterm<R.C'First_Bit>
+If the nondefault bit ordering applies to the composite type, and if a
+@fa<component_clause> specifies the placement of C, denotes the value given for
+the @fa<first_bit> of the @fa<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
+@i<universal_integer>.>
+
+!corrigendum 13.5.2(04)
+
+@drepl
+@xhang<@xterm<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 @i<universal_integer>.>
+@dby
+@xhang<@xterm<R.C'Last_Bit>
+If the nondefault bit ordering applies to the composite type, and if a
+@fa<component_clause> specifies the placement of C, denotes the value given for
+the @fa<last_bit> of the @fa<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 @i<universal_integer>.>
+
+!corrigendum 13.5.3(8)
+
+@drepl
+@xbullet<If Word_Size = Storage_Unit, then the implementation should support
+the nondefault bit ordering in addition to the default bit ordering.>
+@dby
+@xbullet<The implementation should support the nondefault bit ordering in
+addition to the default bit ordering.>
+
+@xindent<@s9<NOTES@hr
+13 Bit_Order clauses make it possible to write
+@fa<record_representation_clause>s that can be ported between machines having
+different bit ordering. They don't guarantee transparent exchange of data
+between such machines.>>
+
+!ACATS Test
+
+Create a test to check that the non-default bit order is supported and creates
+the correct layout (for IEEE floats, for instance.)
 
 !appendix
 

Questions? Ask the ACAA Technical Agent