CVS difference for ais/ai-00051.txt

--- ais/ai-00051.txt	1999/03/23 18:04:34	1.3
+++ ais/ai-00051.txt	1999/11/29 21:14:21	1.4
@@ -1,4 +1,4 @@
-!standard 13.03    (42)                               99-03-22  AI95-00051/09
+!standard 13.03    (42)                               99-11-29  AI95-00051/10
 !class binding interpretation 95-06-25
 !status work item 98-04-01
 !status ARG Approved (subject to letter ballot)  8-0-2  97-11-14
@@ -12,7 +12,7 @@
 !difficulty Medium
 !subject Size and Alignment Clauses for Objects
 
-!summary 99-03-22
+!summary
 
 This AI addresses the requirements for which Size and Alignment clauses
 must be supported for objects.  For Size and Alignment of subtypes, see
@@ -67,9 +67,22 @@
 undefined.
 
 4. For a non-aliased object, the implementation need not support an
-Alignment clause unless the Alignment evenly divides the size (in
-storage elements) of the object.
+Alignment clause unless:
 
+    - For a signed integer, the Alignment is less than or equal to that of
+      the largest signed integer type supported by the implementation.
+
+    - For a modular integer, the Alignment is less than or equal to that of
+      the largest modular type supported by the implementation.
+
+    - For an object of an enumerated type, the Alignment is less than or
+      equal to that of the largest signed integer type, or the largest
+      modular type, which ever is least aligned.
+
+For fixed point, floating point, access, and composite objects, the
+implementation need not support any Alignment other than what would be
+chosen by default.
+
 In addition, the following Implementation Advice (not Recommended Level
 of Support) is added:
 
@@ -79,7 +92,7 @@
 object.  If the view is constrained, the Size should reflect the current
 size of the object, given its current discriminant values.
 
-!question 96-09-05
+!question
 
 First question: The recommended level of support for the Size attribute
 of an object (in RM-13.3(42,43)) implies that the following should be
@@ -111,13 +124,15 @@
 size (perhaps 4*8) or the maximum size (perhaps 104*8)?  The RM does not
 answer this question.
 
-!recommendation 96-04-17
+!recommendation
 
 (See summary.)
+
+!wording
 
-!wording 96-04-17
+To Be Determined.
 
-!discussion 96-11-16
+!discussion
 
 First question:
 
@@ -220,6 +235,62 @@
 the object.  For scalars, however, all bits in the representation of the
 object should be set to some meaningful value.
 
+
+Similar reasoning applies to Alignment clauses for non-aliased objects.
+It seems unreasonable to require arbitrary values for discrete types. Values
+already supported for the class make sense, since the implementation already
+knows how to do such alignments. But requiring additional alignments simply
+add to the implementation burden. There may be hardware requirements on the
+alignment of an integer. For instance, some machines require 32-bit integers
+to be 32-bit aligned. An implementation for such hardware should not be
+required to support 8-bit aligned 32-bit integers. (* Oops: The rules as
+written require mis-aligned integers. Is this a bug?? *) Similarly, there may
+be hardware requirements on the alignment of fixed point, floating point, and
+access types, so we place no requirements other than to support "confirming"
+Alignment clauses. For composite objects, it might be an implementation burden
+to require arbitrary alignments (even within those required by the language),
+as there may be stricter requirements on the component subtypes or on the
+type as a whole. Again, consider the example of implementing small packed
+arrays of Booleans in the same manner as modular types. If there exist
+Alignments for modular types that are not supported, then these Alignments
+can't be supported for such packed arrays.
+
+Relevant wording from the RM follows:
+
+29   The recommended level of support for the Alignment attribute for
+subtypes is:
+
+   30  An implementation should support specified Alignments that are
+       factors and multiples of the number of storage elements per word,
+       subject to the following:
+
+   31  An implementation need not support specified Alignments for
+       combinations of Sizes and Alignments that cannot be easily loaded
+       and stored by available machine instructions.
+
+   32  An implementation need not support specified Alignments that are
+       greater than the maximum Alignment the implementation ever
+       returns by default.
+
+33   The recommended level of support for the Alignment attribute for objects
+is:
+
+   34  Same as above, for subtypes, but in addition:
+
+   35  For stand-alone library-level objects of statically constrained
+       subtypes, the implementation should support all Alignments
+       supported by the target linker.  For example, page alignment is
+       likely to be supported for such objects, but not for subtypes.
+
+These recommendations are hard requirements for implementations that
+support the Systems Programming Annex, by C.2(2) (see above)
+
+These requirements are both vague, and possibly require implementations to
+support non-natural alignments. The vague requirements cannot be depended on
+by users. They are replaced by this AI (for objects) and by AI-00109 (for
+subtypes).
+
+
 ----------------
 
 Second question: In the example, X'Size should be the max size.  Here's
@@ -285,7 +356,7 @@
 by the language in these cases anyway.  A hard requirement is uncalled
 for in this case (even for the SP Annex).
 
-!appendix 96-09-04
+!appendix
 
 !section 13.3(42)
 !subject Object'Size