CVS difference for ais/ai-00133.txt

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

--- ais/ai-00133.txt	2004/03/02 04:44:58	1.9
+++ ais/ai-00133.txt	2004/03/03 00:21:34	1.10
@@ -1285,3 +1285,87 @@
 
 ****************************************************************
 
+From: Dan Eilers
+Sent: Tuesday, March  2, 2004  11:58 AM
+
+Robert Dewar wrote:
+> Well I will have to analyze this more carefully. Do you think GNAT
+> is wrong with respect to the definition in the Ada 95 RM -- it seems
+> right to me. All the attribute does in Ada 95 is to renumber the
+> bits in an addressing unit ...
+
+The existing RM wording is muddled, and subject to multiple interpretations.
+RM 13.5.3 paragraph 2, says that bit_orders of high_order_first and
+low_order_first correspond to big endian and little endian, respectively.
+
+GNAT gives the warning:
+   warning: Bit_Order clause does not affect byte ordering
+
+But it is nonsensical to interpret "big endian" and "little endian"
+in RM 13.5.3(2) as not referring to byte ordering.
+
+If this turns out to be too big an incompatibility for GNAT users,
+then it might make sense to add a new attribute byte_order, which
+does what AI 133 prescribes for bit_order, and then make bit_order
+obsolete.
+
+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
+such rep clauses have no effect.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March  2, 2004  4:09 PM
+
+> But it is nonsensical to interpret "big endian" and "little endian"
+> in RM 13.5.3(2) as not referring to byte ordering.
+
+I strongly disagree that it is nonsensical. It makes perfect sense
+and is what was intended by the design. Big-endian and Little-endian
+clearly refer to both bit and byte order (since the two always go
+together -- yes yes, except on the 68K -- read my book to find out
+how idiotic that decision was :-)
+
+Saying that something is nonsensical is not an argument, in fact
+it is a lack of argument :-)
+
+Yes, that means it only works for an addressing unit, which means
+that it only is really useful if the addressing unit is large, hence
+the limitation in the RM, but a lot of our users have found it useful
+for ordering of bits within a byte, and indeed Randall Anderson and
+I worked out a scheme for completely handling big-little endian
+compatibility that works very nicely, but depends on having this
+renumbering of bits.
+
+> If this turns out to be too big an incompatibility for GNAT users,
+> then it might make sense to add a new attribute byte_order, which
+> does what AI 133 prescribes for bit_order, and then make bit_order
+> obsolete.
+
+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!
+
+> 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*
+
+> such rep clauses have no effect.
+
+Wrong, the warning is on a field by field basis ...
+
+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 :-)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent