CVS difference for ais/ai-10291.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-10291.txt

--- ais/ai-10291.txt	2005/10/31 05:18:47	1.5
+++ ais/ai-10291.txt	2005/12/20 02:34:15	1.6
@@ -902,3 +902,560 @@
 mentioned above, it cannot easily be fixed.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, February 13, 2005 11:03 AM
+
+This contains Randy's alternative to 13.1(7).
+
+---
+
+In the interests of bringing this discussion to a higher level, let me
+propose an alternative to Tucker's wording for 13.1(7):
+
+    The *representation* of an objects consists of a certain number of bits
+    (the *size* of the object). For an object of an elementary type, these
+    are the bits that are normally read or updated by the machine code
+    when loading, storing, or operating-on the value of the object. For an
+    object of a composite type, these are the bits that are reserved for
+    this object, and that could be read or updated by the machine code
+    when loading, storing, or operating-on the value of the object.
+    If the size of an elementary object is greater than that of its subtype,
+    the additional bits are normally read and updated along with the others.
+    If the size of a composite object is greater than that of its subtype,
+    the additional bits could be read and updated along with the others.
+
+    AARM Notes: In the case of composite objects, we want the implementation
+    to have the flexibility to either do operations component-by-component, or
+    with a block operation covering all of the bits. We don't want to specify
+    a preference in the wording.
+
+    In the case of a properly aligned, contiguous object whose size is a
+    multiple of the storage unit size, no other bits should be read or
+    updated as part of operating on the object. We don't say this normatively
+    because it would be difficult to define "properly aligned" or
+    "contiguous".
+    End AARM Notes.
+
+I'd change 13.1(7.f) to read something like:
+
+    A composite object may include *padding bits* that are not part of any
+    subcomponent of the object. The value of any padding bits is not specified
+    by the language.
+
+This wording gets rid of the notion of padding bits and gaps altogether;
+there is no need to talk about such things. They exist; what happens with
+them we don't care and certainly don't specify. There is no other use of
+them in the Standard, so we don't need to define them. The AARM note only
+exists to acknowledge the possibility of bits that don't belong to any
+component. (Note that elementary types don't have padding bits, as it is
+expected that all bits will be read or written. That's not my idea of
+padding!)
+
+This wording still seems to have problems with non-contiguous objects,
+because one reading implies that no other bits could be involved with a
+composite object. There is a "To Be Honest" in the existing AARM that says
+that this isn't intended to cover them. That seems a bit clunky. I had
+thought that there was a requirement that Size not include any discontguous
+pieces, or that it was implementation-defined in that case, but I can't find
+any such rule (in either direction). Perhaps this should explicitly add that
+Size is implementation-defined for non-contiguous objects. Or that this is
+only talking about contiguous representations. Or something.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Sunday, February 13, 2005  7:33 PM
+
+>This wording still seems to have problems with non-contiguous objects,
+>because one reading implies that no other bits could be involved with a
+>composite object. There is a "To Be Honest" in the existing AARM that says
+>that this isn't intended to cover them. That seems a bit clunky. I had
+>thought that there was a requirement that Size not include any discontguous
+>pieces, or that it was implementation-defined in that case, but I can't find
+>any such rule (in either direction). Perhaps this should explicitly add that
+>Size is implementation-defined for non-contiguous objects. Or that this is
+>only talking about contiguous representations. Or something.
+
+Hmm...  I think that you also need to talk about implementation-defined
+fields in composite objects.  This I think is orthogonal to the two
+options presented.  (Is the tag an implementation defined field or not?)
+
+IMHO if the SPA is supported, a 'Size clause should need only to
+include room for the components of a constrained object. The implication
+is that you don't want the indexes or discriminants to be part of each
+object.  For any subtype they must be somewhere, which makes them
+non-contiguous as well.
+
+However, for objects of a tagged type, the tag needs to be part of the
+object. So the wording for both options should allow that.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, February 13, 2005  9:07 PM
+
+> IMHO if the SPA is supported, a 'Size clause should need only to include
+> room for the components of a constrained object. The implication is that
+> you don't want the indexes or discriminants to be part of each object.
+> For any subtype they must be somewhere, which makes them non-contiguous
+> as well.
+
+I really don't think it is worth catering for the possibility of
+constrained subtypes omitting discriminants, too much trouble for
+too little gain.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Monday, February 14, 2005  4:05 AM
+
+> I really don't think it is worth catering for the possibility of
+> constrained subtypes omitting discriminants, too much trouble for
+> too little gain.
+
+Good point.  What I really had in mind was constrained subtypes of types
+without default discriminants.  We could probably spend a lot of time
+discussing cases and solutions, etc.  But the point of my post was that
+the option eventually selected should discuss the issue to clarify if
+and when it is required.  More important though, is that there should be
+an agreement on whether or not such fields (and implementation-defined
+fields) are included in the 'Size.
+
+The issue of reading varying length records into objects with
+unconstrained types is usually best dealt with by overriding 'Read and
+'Write.  The issue I am concerned about is where you are doing
+memory-mapped I/O and the stream model is not appropriate.  For example,
+devices where there are a number of memory-mapped registers, or where
+you have a randomly accessible buffer.
+
+Yes, it would be nice if an implementation supported constrained
+subtypes with implicit bounds or discriminants in these cases.  It isn't
+vital.  But if, whatever the final decision in this area is, the writeup
+makes it clear that the specified size does or does not include
+separately (or implicitly) stored discriminants, it will tend to reduce
+variability between implementations, and help users.
+
+Having said all that, I think that the best answer is that implicit or
+non-contiguous fields should not be considered when a user specifies
+'Size.  That way when porting code from an implementation that does
+support non-contiguous or implicit fields to one that doesn't, the code
+will be rejected at compile time.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, February 14, 2005  4:13 PM
+
+> Good point.  What I really had in mind was constrained subtypes of types
+> without default discriminants.  We could probably spend a lot of time
+> discussing cases and solutions, etc.  But the point of my post was that
+> the option eventually selected should discuss the issue to clarify if
+> and when it is required.  More important though, is that there should be
+> an agreement on whether or not such fields (and implementation-defined
+> fields) are included in the 'Size.
+
+Most certainly the discriminants should be included in 'Size
+
+As for other impl-defined fields, are you sure you want to mandate
+the implementation here, could be onerous for an implementation
+that depends on impl defined fields for holding offsets.
+
+> Yes, it would be nice if an implementation supported constrained
+> subtypes with implicit bounds or discriminants in these cases.  It isn't
+> vital.  But if, whatever the final decision in this area is, the writeup
+> makes it clear that the specified size does or does not include
+> separately (or implicitly) stored discriminants, it will tend to reduce
+> variability between implementations, and help users.
+
+How does this reduce variability unless there really are implementations
+that allow separately or implicitly stored discriminants? Are there such?
+>
+> Having said all that, I think that the best answer is that implicit or
+> non-contiguous fields should not be considered when a user specifies
+> 'Size.  That way when porting code from an implementation that does
+> support non-contiguous or implicit fields to one that doesn't, the code
+> will be rejected at compile time.
+
+Yes, that sounds reasonable, though if there no such implementatoins, this
+could perfectly well be left moot.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Tuesday, February 15, 2005  9:36 PM
+
+> Yes, that sounds reasonable, though if there no such implementatoins,
+> this
+> could perfectly well be left moot.
+
+I felt I should respond to this with a real example.  Unfortunately, I
+have to get a bit into how modern radar systems work to explain how the
+mutant records feature in the Alsys compiler was used to significantly
+improve ease of coding on at least one radar project.
+
+In a modern multimode radar the data collected changes with the major
+modes and with other settings.  Let me go off topic a bit here to
+explain what goes on.  Think of a radar with a rotating antenna, in the
+old days the data from the returns were displayed directly on a PPI,
+plot position indicator.  A CRT was used with the beam sweeping out from
+the center of the screen for each pulse emitted, and rotating around the
+center of the screen with each pulse.   Modern radars don't work
+anything like that, but it gives us some terminology.  One 360 degree
+rotation (or side to side and back oscillation) of the antenna is a
+sweep, and each line on the  screen is a  scan line.
+
+In a modern radar, especially in pulse doppler mode, there may be many
+transmitter pulses per scan line, and each successive scan line will
+often use a different set of parameters for the pulse sequence.  This
+allows the distance to targets to be disambiguated, and using another
+set of parameters for the same scan line or set of scan lines,
+eliminates blind spots.
+
+Since the radar needs to be constantly changing the pulse settings for
+pulse doppler mode, most PD radars also support other major modes, and
+the sky can be divided into sectors with different radar modes or
+parameters used in each sector.  (In fact in some radars, the number of
+scans per degree of rotation can also change.)
+
+Now to get back to Alsys mutant records.  On the particular radar
+project I am thinking of, the computer controlling the radar transferred
+instructions for the next sweep and then received the data in a
+dual-ported memory called the frame buffer.  Obviously the data in the
+frame buffer, although it had already been partially processed by
+electronics hardware, was laid out in a  way that is determined by the
+hardware.  The software of course has to know exactly where to look for
+the data and if you treat each the data for each scan as an Ada variant
+record, the discriminants are not stored in the frame buffer.
+
+Here is where the Alsys mutant records came to the rescue.  The
+discriminants for any scan were pushed onto the stack, in practice for a
+full sweep at a time, and all that had to be done was to use a special
+memory manager to provide the right pointer for each scan's data.  (The
+project was using an Ada 83 version of Alsys when I was involved, but
+the specialized allocator maps perfectly to the concept of storage pools
+in Ada 95.)
+
+Doing this hugely simplified the software.  Rather than have to pass
+lots of parameters around, when passing a scan to a procedure required
+only one parameter, independent of the complexity of the data structure
+for that particular type of scan.  Well actually some of the procedures
+for pulse doppler mode needed to process adjacent scans, so they had two
+parameters.  I won't go into all of the complex processing going on, get
+a good book on radar theory, and be sure you are familiar with the
+Chinese Remainder Theorem, Z and Fourier transforms, convolution and so
+on, so that all you need to learn is how it all applies to radar. ;-)
+
+So there is a specific case where (implementation dependent) use of
+Alsys mutant records probably saved 15% during  the software development
+effort.  If the data were misaligned, there was only one small section
+of code where it could happen. Usually we then had to go talk to the
+hardware engineers and find out what had changed, but it was possible to
+reach that conclusion much quicker. Similarly when the hardware people
+changed the details, and remembered to tell us about it, things had to
+be changed in only one place.  Note also that this was definitely a case
+where the random access nature of the frame buffer was relied on.  Some
+of the data laid down by the hardware was silently discarded, such as
+during the blanking intervals when the receiver gain was turned to zero
+and the transmitter would be swamping any real data anyway.
+
+More important was the ability to simultaneously look at adjacent pairs
+of scans, or in some cases to look at data that was milliseconds to
+seconds old when  attempting to resolve confusion between targets seen
+in the same scan.  The data from successive pulses is aggregated in the
+first pass at detecting  targets in pulse doppler mode.  However, in
+addition to the disambiguation using successive scans, you can reexamine
+the original data and attempt to resolve the target distance directly.
+Not all that good but if you are trying to combine two sets of
+detections from adjacent scans knowing that this detection was at least
+50 miles away but not more than 100 miles can be a big help in the
+disambiguation.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, February 15, 2005  10:21 PM
+
+Not sure what to make of this
+
+a) ALsys mutant records were VERY limited, they applied only for
+stand alone objects .. components were always handled by allocating
+a fixed amount of space.
+
+b) If you really need pointers, that's easily programmed, with
+very little overhead in terms of programming effort.
+
+c) No full Ada 95 implementation is using this approach anyway
+
+d) What has this to do with separated discriminants (Alsys
+mutant records did not store discrimninants separately).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 16, 2005  12:34 PM
+
+> Yes, that sounds reasonable, though if there no such implementatoins, this
+> could perfectly well be left moot.
+
+I don't know how that could work for implicit components. Certainly we don't
+want to have to lie about 'Size for objects; we want it to reflect the
+actual memory allocated. (At least I hope it is supposed to reflect actual
+memory; otherwise I can't imagine what value it would have.) Since implicit
+components (like array descriptors) can be in the middle of a record (it
+would essentially ban many implementation techniques if we were to say
+otherwise - because you would have a situation where multiple things would
+need to be allocated last), I can't imagine how we could not include them in
+'Size.
+
+OTOH, non-contiguous fields could be left out. It's almost a coin toss as to
+which is the most useful. Leaving them out means that the 'Size is an
+accurate representation of the footprint of an object (the address of the
+following object would always be the address of the first object plus the
+size). OTOH, including non-contiguous fields in 'Size means that 'Size is an
+accurate representation of the memory used by the object. These are really
+two different questions, and its unfortunate that we don't have two
+different attributes to answer these (that is another reason that we need a
+standard 'Object_Size, which we won't get, sadly).
+
+Ada 95 seems to lean toward including the non-contiguous fields in 'Size,
+and (less clearly) leaving out implicit ones, which IMHO is the worst
+possible decision. (Which is usually the case with Ada 95 and 'Size.)
+
+> b) If you really need pointers, that's easily programmed, with
+> very little overhead in terms of programming effort.
+
+Give me a break! You could equally well say that about by-reference
+parameters and unconstrained arrays (indeed, C says exactly this). But Ada's
+model is to not make programmers use *explicit* pointers in most cases. I
+think it is an abomination that implementers have been allowed to avoid
+supporting discriminant dependent array components non-contiguously (at
+least as an option), especially in the face of a clear demand for the
+feature (users are told that compilers are allowed to allocate the max, and
+go away please).
+
+> c) No full Ada 95 implementation is using this approach anyway
+
+I presume that this is another dig at Janus/Ada, which uses a non-contiguous
+approach for allocating all objects (including components) with a dynamic
+size. While it's fair to say that Janus/Ada isn't complete when it comes to
+generics (a number of things aren't implemented there), it isn't for most of
+the rest of the language. This area changed little from Ada 83 (other than
+the introduction of storage pools), and we certainly implement everything in
+this area. While it probably has some bugs (what doesn't), and a known
+storage leak issue (which of course has nothing to do with the language
+semantics), I don't see any valid reason to exclude it from the discussion.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 16, 2005  3:22 PM
+
+> Ada 95 seems to lean toward including the non-contiguous fields in 'Size,
+> and (less clearly) leaving out implicit ones, which IMHO is the worst
+> possible decision. (Which is usually the case with Ada 95 and 'Size.)
+
+I disagree, in both respects this would be an entirely bizarre interpretation.
+Nonb-contiguous objects are a puzzle for Size in any case, and in practice
+I just don't think this situation arises.
+
+As for implicit fields, of course they have to be included in Size,
+nothing else makes sense.
+
+>>c) No full Ada 95 implementation is using this approach anyway
+>
+>
+> I presume that this is another dig at Janus/Ada, which uses a non-contiguous
+> approach for allocating all objects (including components) with a dynamic
+> size. While it's fair to say that Janus/Ada isn't complete when it comes to
+> generics (a number of things aren't implemented there), it isn't for most of
+> the rest of the language. This area changed little from Ada 83 (other than
+> the introduction of storage pools), and we certainly implement everything in
+> this area. While it probably has some bugs (what doesn't), and a known
+> storage leak issue (which of course has nothing to do with the language
+> semantics), I don't see any valid reason to exclude it from the discussion.
+
+To me the storage leak issue is the point. I don't see that it is practical
+to adopt this implementation approach successfully, and I observe that no
+implementation has done so. Alsys could not compose for components, and
+Janus has a storage leak that is, as far as I can see, pretty fundamental.
+
+I really think this implementation approach is impractical, and I certainly
+don't think the standard need bother about it much. In practice the wording
+in this kind of area is not going to prohibit such implementation approaches
+anyway (leaving by the way one of the most serious non-portabilities in the
+language, though in practice you can pretty much count on the allocate-max
+strategy these days, the old Alsys compiler having long disappeared. If there
+are large scale users of Janus, then that would be an exception, but as long
+as the standard does not completely rule out the Janus approach then it's
+OK (though certainly the intention of the standard should be to rule out
+the storage leak solution).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 16, 2005  6:55 PM
+
+...
+> >While it probably has some bugs (what doesn't), and a known
+> > storage leak issue (which of course has nothing to do with the language
+> > semantics), I don't see any valid reason to exclude it from the discussion.
+>
+> To me the storage leak issue is the point. I don't see that it is practical
+> to adopt this implementation approach successfully, and I observe that no
+> implementation has done so. Alsys could not compose for components, and
+> Janus has a storage leak that is, as far as I can see, pretty fundamental.
+
+It's not fundamental at all. The original problem was that Ada 83 didn't
+have the notion of storage pools, and because of that, we couldn't figure
+out how to deallocate the memory properly. That's not a problem with the Ada
+95 compiler (the storage pool passed into assignment is the correct one for
+allocations and deallocations); the only issue is that fixing this has had a
+lower priority than finishing the Ada 95 implementation and fixing bugs that
+cause things to not work.
+
+The overhead is limited only to mutable types (as you can tell at
+compile-time whether this support is required), so it isn't very widespread.
+The costs could be reduced further by using allocate-on-the-stack when
+possible (certainly during initialization) and by using a never-shrink
+strategy.
+
+> I really think this implementation approach is impractical, and I certainly
+> don't think the standard need bother about it much. In practice the wording
+> in this kind of area is not going to prohibit such implementation approaches
+> anyway (leaving by the way one of the most serious non-portabilities in the
+> language, though in practice you can pretty much count on the allocate-max
+> strategy these days, the old Alsys compiler having long disappeared. If there
+> are large scale users of Janus, then that would be an exception, but as long
+> as the standard does not completely rule out the Janus approach then it's
+> OK (though certainly the intention of the standard should be to rule out
+> the storage leak solution).
+
+Certainly, we don't intend to encourage implementations to have storage
+leaks. It just hasn't been that important to fix it (it only happens in
+relatively obscure cases). But I do think this approach is practical;
+indeed, if I was starting Janus/Ada over from scratch, there are a lot of
+things that I would do differently (generics and the way temporaries are
+handled in our intermediate code are just two). But this implementation is
+not one of them.
+
+I agree about the non-portability, but I've never understood why it has been
+allowed to persist. It's not especially difficult to support this without
+the need to make users specify arbitrary limits which may have nothing to do
+with their algorithms. I can understand supporting allocate-to-the-max,
+especially in the context of restriction No_Implicit_Allocation, but there
+is no real problem with supporting both  so that the majority of users who
+do not have issues with heap use can use this feature as it was intended -
+without arbitrary limitations.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 16, 2005  8:15 PM
+
+> I agree about the non-portability, but I've never understood why it has been
+> allowed to persist. It's not especially difficult to support this without
+> the need to make users specify arbitrary limits which may have nothing to do
+> with their algorithms. I can understand supporting allocate-to-the-max,
+> especially in the context of restriction No_Implicit_Allocation, but there
+> is no real problem with supporting both  so that the majority of users who
+> do not have issues with heap use can use this feature as it was intended -
+> without arbitrary limitations.
+
+Well in our environment, we consider No_Implicit_Allocation to be a required
+default, and we have never had any customers interested in the dynamic
+allocation, so it doesn't have low priority for us, it has no priority.
+
+TO me, the whole business of non-contiguous objects is ugly and messy
+and better avoided, so this is certainly not somethging I would consider
+imnplementing (unless of course some customer came along with a big money
+bag :-)
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Wednesday, February 16, 2005  11:33 PM
+
+> TO me, the whole business of non-contiguous objects is ugly and messy
+> and better avoided, so this is certainly not somethging I would consider
+> imnplementing (unless of course some customer came along with a big money
+> bag :-)
+
+Sigh!   There are two very separate issues here.  One is what
+implementations actually do with respect to implicit and non-contiguous
+fields. For the most part, I think that this should be left to the
+implementations.  If GNAT and RR have different approaches in this area,
+that is a good thing for potential customers.  If you need a particular
+implementation, select a vendor who supports it.  If some vendor wants
+to satisfy everyone, they can support multiple choices via compile-time
+options or pragmas.
+
+However, none of that affects the fact that the Reference Manual should
+be clear on how 'Size and implicit and non-contiguous fields interact.
+This is where the uniformity is needed.  If there is a need for a 'Size
+like attribute that treats non-contiguous and implicit fields
+differently, that is again a place for implementation specific
+attributes, switches or pragmas.  If the RM stays silent on how these
+are treated, then users have no alternative to experimentation in
+determining what the implementation actually does.
+
+Just a sentence saying that "It is implementation specified whether
+'Size includes implicit or non-contiguous fields." would at least
+require that implementors document what they do.  Not the best choice,
+but certainly better than nothing.
+
+>OTOH, non-contiguous fields could be left out. It's almost a coin toss as to
+>which is the most useful. Leaving them out means that the 'Size is an
+>accurate representation of the footprint of an object (the address of the
+>following object would always be the address of the first object plus the
+>size). OTOH, including non-contiguous fields in 'Size means that 'Size is an
+>accurate representation of the memory used by the object. These are really
+>two different questions, and its unfortunate that we don't have two
+>different attributes to answer these (that is another reason that we need a
+>standard 'Object_Size, which we won't get, sadly).
+
+I agree, including about the 'Object_Size.  The problem in the
+non-contiguous case is that often multiple objects can share the same
+non-contiguous descriptors.  For a (contrived) example, you could have a
+type with 23 discriminants and no defaults that only needed four bytes
+for the object specific data.  If a 'Size representation clause
+restricting the objects to 64 (eight bytes), or some implementation
+specific pragma, resulted in an implementation choice of a pointer to
+the  instance data and the object specific data, it would be silly for
+the  implementation to report the 'Size as 800.  If another
+implementation accepted a 'Size of 32.that searched the current stack
+for the instance data, that's okay too.  (I think that would be very
+aggressive, but if an implementation wanted to support it, fine.  Or an
+implementation might only support a 'Size of 32 if the object was not
+nested in a subprogram. i.e. in a library package or in a nested
+sub-package.)
+
+Again though, I am opposed, even in option 2, to requiring
+implementation to support *all* of this, or any particular
+implementation of it.  What I am saying is that the RM needs to specify
+what an implementation should do with respect to 'Size if it does
+support such things.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 17, 2005  1:55 AM
+
+>> Ada 95 seems to lean toward including the non-contiguous fields in 'Size,
+>> and (less clearly) leaving out implicit ones, which IMHO is the worst
+>> possible decision. (Which is usually the case with Ada 95 and 'Size.)
+>
+> I disagree, in both respects this would be an entirely bizarre
+> interpretation...
+
+I agree with Robert here.  If anything, RM95 is crystal clear
+here (which when it comes to 'Size, is admittedly quite rare ;-):
+
+Paragraph 13.3(56) says:
+
+     * For a subtype implemented with levels of indirection, the Size
+       should include the size of the pointers, but not the size of
+       what they point at.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent