CVS difference for ais/ai-00319.txt

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

--- ais/ai-00319.txt	2002/10/10 17:41:47	1.2
+++ ais/ai-00319.txt	2002/10/29 20:24:57	1.3
@@ -444,3 +444,212 @@
 changes to date.)
 
 ****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 10, 2002  5:55 PM
+
+> I spent years arguing about this point with Robert Dewar.
+> I think I'll say "no comment" this time.  ;-)
+
+The reason that subtype specifiability is so important is that otherwise
+you have a fundamental and serious source of non-portability. The compiler
+is free to choose miscellaneous sizes for objects of a subtype, and this
+is a serious source of non-portability. Normally we can pin down
+representations where they cause portability problems, but this is
+one case where you cannot do so in standard Ada 95. We have found the
+ability to specify object sizes for subtypes to be extremely useful in
+practice.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, October 10, 2002  12:58 PM
+
+> 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 agree that the size of an object should not be required to be a
+multiple of its alignment.  This is certainly useful in cases like a
+record containing an Integer followed by a Character (size is 5 bytes,
+alignment is 4 bytes, perhaps).
+
+I don't know what all the compilers (including ours) support in this
+regard.  I know our C-generating compiler has some
+representation-related constraints imposed by C (or implementations of C).
+
+The fact remains that I misunderstood "consistent with the alignment of"
+to mean something non-vague (until I saw the AARM annotation).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 10, 2002  6:33 PM
+
+<<I agree that the size of an object should not be required to be a
+multiple of its alignment.  This is certainly useful in cases like a
+record containing an Integer followed by a Character (size is 5 bytes,
+alignment is 4 bytes, perhaps).>>
+
+I think it is perfectly reasonable for the object size to meet this
+requirement. In GNAT, we would have the Value_Size (and hence 'Size)
+of such a record be 5 bytes, but the object size would be 8 bytes.
+I see no reason for changing this.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 10, 2002  7:16 PM
+
+Note incidentally that in C it is fundamental that the object size is
+a multiple of the alignment (or arrays would never work).
+
+I really think that the gain from insisting on allowing object sizes
+that are not multiples of alignment are minimal.
+
+Certainly we would simply ignore such a requirement (since it would mean that
+the existing backend could not be used).
+
+Consider the cases:
+
+1. Stand alone variables. Here the gain is a tiny saving in space, compared
+with significantly inefficient code (e.g. for the 5 byte record in question,
+can no longer use 8 byte load/store).
+
+2. Arrays, here you definitely expect the alignment. To not align would
+generate simply horrible code.
+
+3. Records. If you have multiple such fields, again without packing you
+would definitely expect alignment
+
+4. The ONLY case where this is relevant is when you have a field in
+a record followed by some other field that has a smaller alignment.
+I really see no reason in insisting on this working, and indeed I am
+not sure what language you would use here.
+
+The bottom line is that in any case there is no language in the RM to
+require that object size is the same as type size, and surely we do not
+want to add such language.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, October 10, 2002  9:13 PM
+
+> I think it is perfectly reasonable for the object size to meet this
+> requirement. In GNAT, we would have the Value_Size (and hence 'Size)
+> of such a record be 5 bytes, but the object size would be 8 bytes.
+> I see no reason for changing this.
+
+I'm not sure what you're saying.  Consider:
+
+    type R1 is
+        record
+            I: Integer;
+            C: Character;
+        end record;
+
+    type R2 is
+        record
+            R1_Comp: R1;
+            C2: Character;
+        end record;
+
+    R2_Obj: R2;
+
+Assume a fairly typical 32-bit machine, with Integer'Alignment = 4.
+
+Are you saying that (in GNAT), R1_Comp is allocated 8 bytes,
+and R2_Obj is allocated 12 bytes?
+
+And are you further saying that this should be *allowed* behavior or
+*required* behavior of all Ada compilers?
+
+A compiler could (according current rules, I believe) allocate 5 bytes
+for R1_Comp, and put C2 immediately after that, for 6 bytes for R2.
+Are you saying that should be forbidden?
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, October 10, 2002  9:17 PM
+
+> Note incidentally that in C it is fundamental that the object size is
+> a multiple of the alignment (or arrays would never work).
+
+Yes.
+
+> I really think that the gain from insisting on allowing object sizes
+> that are not multiples of alignment are minimal.
+>
+> Certainly we would simply ignore such a requirement (since it would mean that
+> the existing backend could not be used).
+
+I do not advocate *requiring* compilers to do any such thing.
+But I think they should be *allowed* to.
+
+> Consider the cases:
+>
+> 1. Stand alone variables. Here the gain is a tiny saving in space, compared
+> with significantly inefficient code (e.g. for the 5 byte record in question,
+> can no longer use 8 byte load/store).
+
+Agreed.
+
+> 2. Arrays, here you definitely expect the alignment. To not align would
+> generate simply horrible code.
+
+Agreed.  Well, at least I expect 'Component_Size to obey the 'Alignment.
+
+> 3. Records. If you have multiple such fields, again without packing you
+> would definitely expect alignment
+
+Right.
+
+> 4. The ONLY case where this is relevant is when you have a field in
+> a record followed by some other field that has a smaller alignment.
+> I really see no reason in insisting on this working, and indeed I am
+> not sure what language you would use here.
+
+Fair enough, but I'm not sure if you're in favor of *forbidding* this,
+or if you just don't want to *require* it.
+
+> The bottom line is that in any case there is no language in the RM to
+> require that object size is the same as type size, and surely we do not
+> want to add such language.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 10, 2002  10:04 PM
+
+<<And are you further saying that this should be *allowed* behavior or
+*required* behavior of all Ada compilers?>>
+
+Allowed, not required
+
+<<A compiler could (according current rules, I believe) allocate 5 bytes
+for R1_Comp, and put C2 immediately after that, for 6 bytes for R2.
+Are you saying that should be forbidden?>>
+
+We would do this only if the record were packed. The trouble with doing
+it unconditionally is that it would generate inefficient code for
+copying the field out of the record. We consider that such inefficiencies
+should be bought only with pragma Packed.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 10, 2002  10:05 PM
+
+<<I do not advocate *requiring* compilers to do any such thing.
+But I think they should be *allowed* to.>>
+
+Yes, of course, they are allowed to now, so what's the issue?
+
+<<Fair enough, but I'm not sure if you're in favor of *forbidding* this,
+or if you just don't want to *require* it.>>
+
+It should be allowed but not required
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent