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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? Date: Fri, 11 May 2018 23:16:08 +0300 Organization: Tidorum Ltd Message-ID: References: <2821b8e0-2c64-4621-b65e-337027fc121e@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net c3MlU4GmsqMRmhx5vWhQFgYw6GKh3RxqliqiwqZDoxUHcvIS6A Cancel-Lock: sha1:x2ersgxP/iSU6ZHF7BN4AGiN8zk= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader02.eternal-september.org comp.lang.ada:52286 Date: 2018-05-11T23:16:08+03:00 List-Id: On 18-05-11 14:40 , Dan'l Miller wrote: > On Friday, May 11, 2018 at 4:40:19 AM UTC-5, Niklas Holsti wrote: >> >> The ability to specify Bit_Order for record representations is very >> useful to me, as it allows my programs to be executed both on the target >> HW (big-endian SPARC) and on the development workstations (little-endian >> x86) with exactly the same HW-level input and output. > > Please provide an example of a Bit_Order-based-representation-clause > record that is portable between SPARC and IA-32/AMD64 (that is not > utilizing the GNAT feature in A12-0218, and completely ignoring the > packed-array troublesome case). There is a perennial debate whether > the •proper• usage of Bit_Order on •bug-free• representation clauses > in an Ada compiler already solves the entire topic of A12-0218, > making moot A12-0218 and GNAT's already-extant feature therein. Bit_Order is not Byte_Order; it does not address the byte-endianness problem. Bit_Order merely specifies the order in which bits are numbered in a representation clause. I use record types with specified Bit_Order to access structured 32-bit HW/peripheral control registers (real registers on the SPARC, just RAM variables in the PC). The record types are also 32 bits in size, and the registers are written and read as 32-bit words, not as sequences of 8-bit storage units. My record representation clauses always say "at 0 range ..." and use bit numbers between 0 and 31, so there is never a reference to a ´particular storage unit (octet) within the record: never "at 1 range ..." or some other non-zero storage-unit offset. By using the same Bit_Order on the SPARC and the PC, it is ensured that the 32-bit record values are identical on the SPARC and on the PC, for example when unchecked-converted to 32-bit unsigned integers and displayed in hex. The octet order in memory is still different on the SPARC and the PC, but that is irrelevant to me, because the registers are always accessed as 32-bit words. (On the SPARC, the octet order is not really defined, because the HW control registers must be accessed as whole 32-bit words and cannot be accessed in smaller units.) So my successful use of Bit_Order is not relevant to ai12-0218, which is about the order of storage units in memory, not about the order of numbering bits in a word in record representation clauses. ai12-0218 is relevant to records that are accessed _both_ as a sequence of storage units (for example, for stream I/O) and as a multi-storage-unit record. This is not my case; for stream I/O I have the same approach as Dmitry (I believe): decode/encode octet by octet. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .