CVS difference for ais/ai-00319.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00319.txt

--- ais/ai-00319.txt	2002/10/10 17:14:40	1.1
+++ ais/ai-00319.txt	2002/10/10 17:41:47	1.2
@@ -8,8 +8,7 @@
 
 !summary
 
-A new attribute, 'Object_Size, is defined to cleanly the representation of
-subtypes.
+The new attribute S'Object_Size denotes the size of most objects of subtype S.
 
 !problem
 
@@ -66,8 +65,8 @@
     that implementations that do not round up allocations (just using padding
     to provide alignment) are not required to do any rounding up.
 
-If X denotes an object (including components) of S, X'Size should S'Object_Size,
-unless:
+If X denotes an object (including components) of subtype S, X'Size should
+be S'Object_Size, unless:
     X'Size is specified; or
     The size of X is determined by a component_clause or Component_Size clause; or
     Pragma Pack applies to the type containing component X.
@@ -109,8 +108,25 @@
     subtypes. We allow this freedom, as Rational^H^H^H^H^H^H^H^H some
     implementations may have trouble with static matching if the Object_Sizes
     of subtypes can be different (see 4.9.1). We will let the market decide
-    of subtype specification of Object_Size is necessary.
+    whether subtype specification of Object_Size is necessary.
 
+Change 13.3(50) to:
+
+If the Object_Size of a subtype is not specified, the Size of the 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:
+
+AARM Note:
+    Ramification: If Object_Size is specified, this rule does not apply; the
+    rules for Object_Size apply instead. If Object_Size is not specified,
+    this rule implies that the default Object_Size is the same as the
+    specified Size if the Size allows for efficient independent addressability
+    (which, BTW, is not defined in 9.10).
+
+    Reason: We need to specify what happens if both Object_Size and Size are
+    specified incompatibly.
+
 Change the first sentence of 4.9.1(2) to:
 
 A subtype statically matches another subtype of the same type if they have
@@ -307,5 +323,124 @@
 > (Object_Size has only a weakly suggested value, so it is likely that
 > T'Object_Size = T'Base'Object in the absense of a specification for
                                _Size
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 10, 2002  12:28 AM
+
+> >    -- Requiring subtype specifiability would simplify the wording some, but
+> >       I believe that Rational would scream bloody murder (because that would
+> >       force a legality check to depend on representation). Any ideas on
+> >       avoiding that trap? (The discussion of AI-109 would suggest that there
+> >       is not);
+>
+> I spent years arguing about this point with Robert Dewar.
+> I think I'll say "no comment" this time.  ;-)
+
+Ah, you've just been waiting years for some other poor sucker to take a
+crack at this. :-) :-)
+
+> > A new attribute, 'Object_Size, is defined to cleanly the representation of
+> > subtypes.
+>
+> Last clause no verb.  ;-)
+>
+> At first I thought you meant "specify", but the normal RM style sort of
+> assumes that attributes' primary purpose is to *query*.  So how about
+> something like "The new attribute S'Object_Size denotes the size of
+> certain objects of subtype S."  (I know S'Object_Size is an
+> attribute_reference, not an attribute, but we can be informal here.)
+
+I've used your wording.
+
+> > For every subtype S:
+> >
+> > S'Object_Size	If S is definite, denotes the size (in bits) that the
+> > implementation would choose for the following objects of subtype S:
+> >     * A stand-alone object of subtype S.
+> >     * A record component of subtype S when the record type has
+> >       no representation items applied.
+> >     * An array component of subtype S when the array type has
+> >       no representation items applied.
+>
+> Hmm.  This seems to require that all of these kinds of objects must be
+> the same size.  I have the impression that some compilers don't do that
+> currently, and they should not be forced to change.  (I think some
+> compilers pack arrays and maybe records more tightly than stack frames.
+> True?)
+
+I don't know, but it certainly is my intent that they be the same. Else we
+have the same problem that we have with 'Size (it doesn't mean anything).
+We'll need to talk about this.
+
+> >     We purposely used the vague phrase "consistent with the alignment of S"
+> >     so that implementations that do not round up allocations (just using
+> >     padding to provide alignment) are not required to do any rounding up.
+>
+> I didn't find the term "vague" until you said it was.  I understood it
+> to mean precisely, "S'Object_Size shall be a multiple of S'Alignment".
+
+Because you use that strange model that requires something with an alignment
+of 4 to have a size that is a multiple of it. I (and Janus/Ada) do not use
+such a model. (A byte can have alignment 4, there is no problem with that
+IMHO). In our compiler, "consistent with the alignment of S" has no effect.
+
+So the phrase means whatever makes sense to the implementation. And that's
+good.
+
+> I'm not sure *any* advice is wise, here.  The above appears to give
+> advice on the value of 'Object_Size, but it's really indirectly giving
+> advice on how to lay out objects.  I think compilers should be free to
+> do what they like (when 'Object_Size is not specified).  Certainly any
+> such advice should not contradict what any existing compilers do.
+
+It's ADVICE for a reason. Compilers should be free to ignore it if it makes
+sense. That's true of all ADVICE.
+
+> Anyway, why give advice if it doesn't say anything (as the above
+> vagueness claim seems to be saying)?
+
+No, it says quite a bit. It just doesn't say exactly what alignment rule a
+compiler is going to use, because that is silly (I think the rule that you
+guys use is silly, but I don't see any reason to suggest that you change).
+
+> I presume the above advice is *not* intended to be "Recommended Level of
+> Support" -- i.e., it remains "merely" advice even in the Systems Prog
+> Annex.
+
+Correct. That's why it doesn't use that phrase.
+
+> >     If S is a static signed integer subtype, the implementation should
+> >     support specifying S'Object_Size to be the size of any signed integer
+> >     base type provided by the implementation that is at least as large
+> >     as S'Size.
+>
+> No such thing as "base type".  Why say all this anyway?  Why not just
+> say something about "naturally supported by the hardware"?
+
+Because that NOT what Annex B says about Interfaces, and this ought to be
+consistent with that. I'm fairly confident that this is wrong anyway,
+because of signed/unsigned issues. I'm going to have to revisit it, but no
+time now.
+
+> > Change the first sentence of 4.9.1(2) to:
+> >
+> > A subtype statically matches another subtype of the same type if they have
+> > statically matching constraints and their Object_Sizes (see 13.3) are the
+> > same.
+>
+> This seems like a loophole.  Shouldn't the *default* 'Object_Size be
+> required to be the same for subtypes of the same type with statically
+> matching constraints?
+
+That's required by 13.1(15/1); if it isn't, that paragraph should be fixed
+to do so (that is part of AI-109, but I doubt that AI will ever be
+finished...).
+
+I've noticed another problem as well: I didn't say what happens when both
+Object_Size and Size are specified incompatibly. I've fixed that in draft
+/02. It will be posted on the web site momentarily. (Along with all other
+changes to date.)
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent