CVS difference for ais/ai-00133.txt

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

--- ais/ai-00133.txt	2004/04/06 19:56:54	1.11
+++ ais/ai-00133.txt	2004/09/04 01:13:42	1.12
@@ -1,4 +1,4 @@
-!standard 13.05.03 (00)                               03-10-31  AI95-00133/03
+!standard 13.05.03 (00)                               04-08-27  AI95-00133/04
 !class binding interpretation 96-05-07
 !status work item 96-05-07
 !status received 96-05-07
@@ -51,7 +51,14 @@
 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.]
 
+
 Add after 13.5.1(10)
 
 If the nondefault bit ordering applies to the type, the value of last_bit shall
@@ -69,18 +76,45 @@
 first_bit and last_bit of each component_clause are then interpreted as bit
 offsets in this machine scalar.
 
-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.
-
 
 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, and no
-others.
+integer, floating-point and address formats supported by the machine.
+
+
+Replace 13.5.2(2-4) 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.
+
+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.
+
+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.
+
+[Author's Note: This is a situation where the fact that a representation item
+(the component_clause) is specified has a visible effect. That's unfortunate,
+but I see no alternative, because in the absence of a component_clause for C
+there is no way that we can conjure up the machine scalars out of thin air.]
 
+
 Replace 13.5.3(8) by:
 
 o  The implementation should support the nondefault bit ordering in addition to
@@ -195,7 +229,7 @@
       end record;
 
 While the meaning of large bit numbers is obvious in the default bit ordering,
-it is not obvious in the nondefault bit ordering. Suppose we and compile a big-
+it is not obvious in the nondefault bit ordering. Suppose we compile a big-
 endian record-representation clause, together with a big-endian Bit_Order
 clause, for a little-endian target. The record-representation clause includes
 the component clause:
@@ -248,34 +282,11 @@
 above example) as there may not exist a 32-bit machine scalar on the latter
 target.
 
-[Author's note: Norm had the following definition: "The length of a machine
-scalar is inferred from the highest bit number specified along with its byte
-position in some component clause, rounded up to the next multiple of
-System.Storage_Unit." This means that a machine scalar according to this
-definition could have, say, 42 bytes. That's different from his original
-definition for this term, and it causes confusing effects where you have to
-introduce fillers for representation clauses to do the right thing. His paper
-has an example where a 24-bit component on a 32-bit machine ends up misplaced
-unless a 1-byte filler is explicitly introduced. I think it's better to define
-machine scalars to reflect the "natural" formats of the machine.]
-
 The proposed interpretation is of course incompatible in the sense that, for the
 nondefault bit ordering, it breaks the current rule that bit 8+b of byte a is
 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.
-
-[Author's note: Randy, would it be possible to run a compiler survey to see
-what compilers do with Bit_Order clauses that specify the nondefault bit
-ordering? I suppose that you could use the above example of the IEEE 32-bit
-format.]
-
-The attributes Position, First_Bit and Last_Bit are still normalized, even if
-the nondefault bit ordering is used. This means that if they are used to produce
-a record representation clause they may result in a different layout, because
-the partition in terms of machine scalars will change. Since these attributes
-are not static, any such scenario would involve the intervention of a human
-being or of a program generator, so the oddity is probably acceptable.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent