CVS difference for ais/ai-00133.txt

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

--- ais/ai-00133.txt	2004/03/03 00:21:34	1.10
+++ ais/ai-00133.txt	2004/04/06 19:56:54	1.11
@@ -1369,3 +1369,455 @@
 
 ****************************************************************
 
+From: Dan Eilers
+Sent: Tuesday, March  2, 2004  6:57 PM
+
+>                                         Big-endian and Little-endian
+> clearly refer to both bit and byte order ...
+
+On this we agree completely.
+When the bit_order attribute is used, it should be used to specify
+the interpretation of both the bit and byte order.
+
+> Requiring compilers to manipulate byte order is too large a change
+> in my view, and in any case is not what the original AI was about!
+
+Correct.  AI-133 has absolutely nothing to do with requiring
+compilers to manipulate byte order at run-time.  Instead, it is
+about endian-independent rep clauses, with absolute no run-time
+byte flipping or discontiguous fields.
+
+> Yes, that means it only works for an addressing unit.
+
+No, as shown by Norm Cohen's write up, a proper interpretation
+of the bit_order attribute makes it trivially easy to support
+endian-independent rep clauses that work for more than an addressing
+unit.
+
+> > But I don't think the incompatibility is particularly bad.
+> > For cases where fields do cross byte boundaries there is no
+> > incompatibility because GNAT rejects those.  And GNAT users
+> > are unlikely to use non-default bit_order rep clauses where
+> > fields don't cross byte boundaries, because GNAT warns that
+>          ^^^^^
+> You mean *do* not *don't*
+
+No, I meant exactly what I said.  The only incompatibility is
+when fields don't cross byte boundaries (the other case is
+rejected by GNAT, so no inconsistency), and such use is unlikely
+due to GNAT's warning that the attribute is interpreted not to do
+what the user wants.
+
+> By the way, the approach Randall and I worked out is to have the
+> big-endian machine and little-endian machine order the fields in
+> reverse order, which is easily done with a parametrized rep clause,
+> then use bit order to deal with stuff within a byte, then byte
+> flip the entire record -- yes I know, more detail needed :-)
+
+No such standing on one's head is required.  Read the AI.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March  2, 2004  8:22 PM
+
+> On this we agree completely.
+> When the bit_order attribute is used, it should be used to specify
+> the interpretation of both the bit and byte order.
+
+Well in fact it only specifies bit order, and AI133 does not change
+that.
+
+>>Requiring compilers to manipulate byte order is too large a change
+>>in my view, and in any case is not what the original AI was about!
+
+> Correct.  AI-133 has absolutely nothing to do with requiring
+> compilers to manipulate byte order at run-time.  Instead, it is
+> about endian-independent rep clauses, with absolute no run-time
+> byte flipping or discontiguous fields.
+
+Right, but I think it is useless to solve this sub problem. The
+only interesting problem to solve is interchange information
+between LE and BE machines, and the approach of this AI is
+simply not helpful in that regard.
+
+>>Yes, that means it only works for an addressing unit.
+
+> No, as shown by Norm Cohen's write up, a proper interpretation
+> of the bit_order attribute makes it trivially easy to support
+> endian-independent rep clauses that work for more than an addressing
+> unit.
+
+I find the NC approach unconvincing, I cannot think of a single
+customer problem that we have had in this area (and there are many)
+where this would have helped at all.
+
+> No, I meant exactly what I said.  The only incompatibility is
+> when fields don't cross byte boundaries (the other case is
+> rejected by GNAT, so no inconsistency), and such use is unlikely
+> due to GNAT's warning that the attribute is interpreted not to do
+> what the user wants.
+
+You miss entirely the usual use of this attribute which is something
+like the following.
+
+I want to transfer a byte between a LE and BE machine that has
+field A in the 4 ms bits, and field B in the 4 ls bits.
+
+All I have to do is
+
+    type R is record
+       a,b : integer range 0 .. 15;
+    end record;
+
+    for R'Bit_Order use High_Order_First;
+    for R use record
+       A at 0 range 0 .. 3;
+       B at 0 range 4 .. 7;
+    end record;
+
+This works perfectly and allows the same rep clause on the LE and
+BE machines, and allows data to be interchanged.
+
+No warning, because the rep clause does exactly what is expected.
+And this is a case where fields do not cross byte boundaries.
+
+So I really have no idea what you meant to say in the above para.
+What you did say makes no sense.
+
+>>By the way, the approach Randall and I worked out is to have the
+>>big-endian machine and little-endian machine order the fields in
+>>reverse order, which is easily done with a parametrized rep clause,
+>>then use bit order to deal with stuff within a byte, then byte
+>>flip the entire record -- yes I know, more detail needed :-)
+
+> No such standing on one's head is required.
+
+Yes it is!
+
+> Read the AI.
+
+The whole point of the AI is to solve the problem of consistent
+layout of fields, *WITHOUT PROVIDING* LE/BE data interchange. That's
+clear in the AI.
+
+To solve the LE/BE data interchange issue, you HAVE to have byte
+flipping. There is no avoiding this, it's fundamental.
+
+I find the AI in its current form worse than useless. It further
+complicates the understanding of this attribute in a bizarre and
+complex manner without providing any additional useful functionality.
+The only problem worth solving here is interchange of data between
+the two machine types. The current definition does this within bytes
+but does not deal with fields going over byte boundaries or fields
+occupying more than one byte. The AI solves neither of these problems.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Wednesday, March  3, 2004  11:35 AM
+
+Today, Robert Dewar wrote:
+> The only interesting problem to solve is interchange information
+> between LE and BE machines, and the approach of this AI is
+> simply not helpful in that regard.
+
+Last week, Robert Dewar wrote:
+> What customers want of course is some magic incantation to allow
+> their big endian dependent apps to run on little endian machines
+> without any change. They are not going to get this :-)
+
+Yes it is true that AI-133 is not the least bit helpful with regard
+to the data interchange problem, and yes it is true that Ada0Y is
+not going to provide a solution to that problem.
+
+What AI-133 does provide is a solution to is the endian-independent
+rep clause problem.  This problem is not some unimportant subproblem.
+It has been the subject of more than one published technical article,
+it is the subject of repeated c.l.a. inquiries, it was the subject of
+more than one Ada9x revision request, and such revision revision requests
+were vetted by experts and accepted in the Ada9x revision requirements
+document.
+
+However, Ada95's solution to endian-independent rep clauses was botched.
+AI-133 fixes that in a way that does not cause any runtime overhead or
+any compile time complexity, or any difficulties in understanding the
+attribute.  Consecutive bitoffsets in non-default bitorder are simply
+interpreted as specifying contiguous storage locations, just as they do
+in default bitorder.
+
+We have implemented Norm's solution.  It was trivial to do, and
+it works great.  Our user's don't get any nonsensical error messages
+about purported attempts to specify non-contiguous fields, or any
+nonsensical warnings about the bit_order attribute not controlling
+byte order.
+
+> You miss entirely the usual use of this attribute which is something
+> like the following.
+>
+> I want to transfer a byte between a LE and BE machine that has
+> field A in the 4 ms bits, and field B in the 4 ls bits.
+
+The AI makes it crystal clear that the bit_order attribute is _not_
+intended to solve the problem of data interchange between BE and LE
+machines.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March  3, 2004  6:49 PM
+
+> What AI-133 does provide is a solution to is the endian-independent
+> rep clause problem.  This problem is not some unimportant subproblem.
+> It has been the subject of more than one published technical article,
+> it is the subject of repeated c.l.a. inquiries, it was the subject of
+> more than one Ada9x revision request, and such revision revision requests
+> were vetted by experts and accepted in the Ada9x revision requirements
+> document.
+
+The Ada 95 RM itself was vetted by experts, and what is says is
+reasonable, and in fact the facilities there DO solve the endian
+transfer problem for a limited set of cases.
+
+> However, Ada95's solution to endian-independent rep clauses was botched.
+
+I do not agree that this is botched.
+
+> AI-133 fixes that in a way that does not cause any runtime overhead or
+> any compile time complexity, or any difficulties in understanding the
+> attribute.  Consecutive bitoffsets in non-default bitorder are simply
+> interpreted as specifying contiguous storage locations, just as they do
+> in default bitorder.
+
+I do not regard AI-133 as useful
+
+> We have implemented Norm's solution.  It was trivial to do, and
+> it works great.
+
+I trust this is under some switch, since I think it is clearly
+non-conforming behavior otherwise.
+
+> Our user's don't get any nonsensical error messages
+> about purported attempts to specify non-contiguous fields, or any
+> nonsensical warnings about the bit_order attribute not controlling
+> byte order.
+
+Those warnings are extremely important in practice. Every user who
+has queried the warnings was in fact trying to solve the problem of
+moving data between different endianess machines.
+
+>>You miss entirely the usual use of this attribute which is something
+>>like the following.
+>>
+>>I want to transfer a byte between a LE and BE machine that has
+>>field A in the 4 ms bits, and field B in the 4 ls bits.
+
+> The AI makes it crystal clear that the bit_order attribute is _not_
+> intended to solve the problem of data interchange between BE and LE
+> machines.
+
+Sorry, but the AI is irrelevant. The feature as described in the RM
+today *IS* useful in solving the data interchange problem, and is
+used that way routinely. You may read the AI this way, but even if
+this reading of the AI is correct, the AI has no normative effect
+on the standard.
+
+Actually what I think the AI is saying is that Bit_Order cannot be
+used to solve all such problems. And that I agree with!
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Wednesday, March  3, 2004  7:05 PM
+
+Robert Dewar wrote:
+> The Ada 95 RM itself was vetted by experts, and what is says is
+> reasonable, and in fact the facilities there DO solve the endian
+> transfer problem for a limited set of cases.
+
+We can agree to disagree that what the RM currently says about
+bit_order is reasonable.  Certainly there is no dispute that the
+current RM wording does not solve the problem of endian-independent
+rep clauses.
+
+> I do not regard AI-133 as useful
+
+We can agree to disagree on this.  But certainly AI-133 _does_ solve
+the problem of endian-independent rep clauses.
+
+> > We have implemented Norm's solution.  It was trivial to do, and
+> > it works great.
+>
+> I trust this is under some switch, since I think it is clearly
+> non-conforming behavior otherwise.
+
+No, it's in standard mode, using Dewar's rule that the RM does
+not require nonsense, and discontiguous fields are nonsense.
+
+> > Our user's don't get any nonsensical error messages
+> > about purported attempts to specify non-contiguous fields, or any
+> > nonsensical warnings about the bit_order attribute not controlling
+> > byte order.
+>
+> Those warnings are extremely important in practice.
+
+I agree that under your interpretation of the bit_order attribute,
+it is extremely important to warn users of this unexpected behavior.
+
+> Actually what I think the AI is saying is that Bit_Order cannot be
+> used to solve all such problems. And that I agree with!
+
+The AI says much more than this.  It proposes a perfectly fine
+solution to the endian-independent rep clause problem.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March  3, 2004  7:38 PM
+
+Dan Eilers wrote:
+
+> No, it's in standard mode, using Dewar's rule that the RM does
+> not require nonsense, and discontiguous fields are nonsense.
+
+Not at all. Non-contiguous fields definitely arise when transferring
+data from LE to BE machines. It would indeed be useful to support
+them generally. We have this on a list of useful (but difficult)
+enhancements.
+
+> I agree that under your interpretation of the bit_order attribute,
+> it is extremely important to warn users of this unexpected behavior.
+
+You miss the point. In *all* the cases where we have discussed this
+warning, customers wanted to solve the problem of transferring data
+between machines. We would still give the warning even if the AI
+were implemented, since in our experience, the interpretation that
+the AI gives by default is NOT what the customer needed, wanted,
+or expected.
+
+> The AI says much more than this.  It proposes a perfectly fine
+> solution to the endian-independent rep clause problem.
+
+First, I do not agree that this is a significant issue, divorced
+from the data independence issue. Second, the feature as it exists
+now IS useful for solving data independence, and is best seen as
+a limited facility for this purpose.
+
+That's the way the RM is written now, and I prefer the way it is
+written now to your preferred rewriting.
+
+If you need a solution to the problem of endian independent rep
+clauses (they are quite easy to write now with appropriate
+parametrization), I think it is a bad idea to hijack this
+feature in this manner, and I find the fundamental trick in
+this AI to be an unpleasant and confusing kludge.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Wednesday, March  3, 2004  8:29 PM
+
+Robert Dewar wrote:
+> Non-contiguous fields definitely arise when transferring
+> data from LE to BE machines. It would indeed be useful to support
+> them generally. We have this on a list of useful (but difficult)
+> enhancements.
+
+I fully agree that it would useful for Ada at some point to solve
+the data interoperability problem.   But since nobody has proposed
+a solution, I don't see any chance for 200Y.   Feel free to propose
+an AI for that, but don't hijack AI-133, and don't dismiss AI-133
+on the grounds that it doesn't solve that problem.
+
+I continue to believe that the bit-order attribute is not intended
+as a solution to the data interoperability problem.  This was an
+early Ada9x study topic, but it got dropped from the final revision
+requirements document, although solving the endian-independent
+rep clauses problem was retained as a Ada9x requirement.
+
+> We would still give the warning even if the AI
+> were implemented, since in our experience, the interpretation that
+> the AI gives by default is NOT what the customer needed, wanted,
+> or expected.
+
+Well, if AI-133 were implemented, the revised 200Y RM would would
+presumably make it clear to users what to expect from the feature.
+If you still wanted to give a warning, that would be fine with me.
+
+> First, I do not agree that this is a significant issue, divorced
+> from the data independence issue.
+
+We can agree to disagree on this.  Certainly users raise this
+issue repeatedly, particularly since Ada doesn't support
+conditional compilation.  Endian-independent rep clauses also
+happen to come in handy for implementing the floating point
+attributes, such as 'exponent.
+
+> Second, the feature as it exists
+> now IS useful for solving data independence, and is best seen as
+> a limited facility for this purpose.
+
+We can agree to disagree on this.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March  3, 2004  9:00 PM
+
+> We can agree to disagree on this.
+
+Not really, the disagreement has consequences (whether or
+not to proceed on this AI), so an agreement of this nature
+settles nothing.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March  3, 2004  9:02 PM
+
+> I fully agree that it would useful for Ada at some point to solve
+> the data interoperability problem.   But since nobody has proposed
+> a solution, I don't see any chance for 200Y.   Feel free to propose
+> an AI for that, but don't hijack AI-133, and don't dismiss AI-133
+> on the grounds that it doesn't solve that problem.
+
+I repeat I find the "solution" to be a horrible and confusing
+kludge. It also prevents a more useful implementation of Bit_Order
+(GNAT warns now, but it could do things properly instead).
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Wednesday, March  3, 2004  10:46 PM
+
+
+Robert Dewar wrote:
+> > We can agree to disagree on this.
+>
+> Not really, the disagreement has consequences (whether or
+> not to proceed on this AI), so an agreement of this nature
+> settles nothing.
+
+We can agree to let the ARG settle the dispute.
+Clearly we are not going to change each other's
+opinion by repeatedly saying we think the feature
+is useful or we think it's not.
+
+> I repeat I find the "solution" to be a horrible and confusing
+> kludge. It also prevents a more useful implementation of Bit_Order
+> (GNAT warns now, but it could do things properly instead).
+
+It would move the discussion along if you said what it was
+about the proposed "solution" that you find to be so horrible.
+Is it simply that the solution gets in the way of future
+GNAT plans for solving the data interoperability problem?
+Is it the way the solution is worded?
+Surely you don't find it horrible and confusing that a
+user would want to write portable rep clauses.  Its
+certainly less of a kludge than the "parameterized"
+rep clauses you suggested as an alternative.
+When IEEE defines the layout of floating point types
+do they use "parameterized" descriptions?
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent