From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,81bce7ee9133fb42 X-Google-Attributes: gid103376,public From: ncohen@watson.ibm.com (Norman H. Cohen) Subject: Re: GNAT Ada for DOS - Reading Integers Problem Date: 1996/02/21 Message-ID: <4gfsuq$10f5@watnews1.watson.ibm.com>#1/1 X-Deja-AN: 140460988 distribution: world references: <4g2efj$d5d@susscsc1.rdg.ac.uk> <4gdivm$10f5@watnews1.watson.ibm.com> organization: IBM T.J. Watson Research Center reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada Date: 1996-02-21T00:00:00+00:00 List-Id: In article , dewar@cs.nyu.edu (Robert Dewar) writes: |> Norman says |> |> "No, the purpose of the 'Bit_Order attribute is not to perform |> big-endian/little-endian data conversion at run-time, but to assert that |> bit numbers in record-representation clauses should be interpreted at |> compile time according to either big-endian or little-endian conventions." |> |> That's wrong, if a compiler DOES allow this compile time control, then |> normal change-of-representation coding (i.e. have two derived types, one |> with one bit order and one with the other, and use conversions to flip |> between the two) should work fine. What does the change-of-representation approach have to do with the 'Bit_Order attribute? You could accomplish that even with Ada 83: type Byte is range 0 .. 255; for Byte'Size use 8; (The names Low and High suggest that Half_Word is an LE representation and Byte_Swapped_Half_Word is a BE representation, but the example is symmetric.) RM95-13.5.3(1) is quite clear about the 'Bit_Order attribute: "The Bit_Order attribute specifies the interpretation of the storage place attributes." (The storage-place attributes are R.C'Position, R.C'First_Bit, and R.C'Last_Bit. The values in a record-representation clause determine the values of these attributes, as described in RM95-13.5.1(13).) |> Implementing the unnatural order is non-trivial (and implementing the |> above change of representation even more non-trivial). Furthermore the |> RM does not require this feature be implemented, so don't count on it |> being available! What Robert means is that support for the nondefault value for 'Bit_Order is not required by the RM (for any of the most common architectures). However, the representation clauses above, which don't use the 'Bit_Order attribute, ought to work on any machine with 8-bit bytes. Perhaps Robert is suggesting that the same effect could be achieved by writing type Half_Word is record Low : Byte; High : Byte; end record; for Half_Word'Bit_Order use Low_Order_First; for Half_Word use record Low at 0 range 0 .. 7; High at 0 range 8 .. 15; end record; type Byte_Swapped_Half_Word is new Half_Word; for Byte_Swapped_Half_Word'Bit_Order use High_Order_First; causing Byte_Swapped_Half_Word to inherit the literal text Low at 0 range 0 .. 7; High at 0 range 8 .. 15; from its parent's record representation clause, but to interpret that text big-endianly instead of little-endianly! This is certainly a creative interpretation, but I can't believe it is what the Founding Fathers intended. RM95-13.1(15) states that "A derived type inherits each type-related aspect of its parent type that was directly specified before the declaration of the derived type ...," but surely it is the actual layout of the parent type rather than the program text describing that layout that should be considered an "aspect of representation". After all, if the record-representation clause is omitted, the program text will cease to exist, but the parent type will still have some default layout. (Fortunately, the Founding Fathers follow this newsgroup and can provide a definitive answer about their Original Intent.) -- Norman H. Cohen ncohen@watson.ibm.com