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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38ceb882eed41e1e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-11 06:45:09 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!jfk3-feed1.news.digex.net!dca6-feed1.news.digex.net!intermedia!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3BC59C8E.BADA210D@Raytheon.com> From: Mark Johnson X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Size and pack References: <9ff447f2.0110100005.2503bb00@posting.google.com> <9ff447f2.0110102224.5c470e2c@posting.google.com> <3bc55ea1.3939494@news.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 11 Oct 2001 08:20:15 -0500 NNTP-Posting-Host: 192.27.48.44 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1002806438 192.27.48.44 (Thu, 11 Oct 2001 08:20:38 CDT) NNTP-Posting-Date: Thu, 11 Oct 2001 08:20:38 CDT Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:14258 Date: 2001-10-11T08:20:15-05:00 List-Id: John McCabe wrote: > On 10 Oct 2001 23:24:27 -0700, byhoe@greenlime.com (Adrian Hoe) wrote: > [snip] > You may need to be concerned about endianness- although there is > a 'Bit_Order attribute, in my experience a compiler is unlikely to > allow you to specify a bit order that is contrary to its native > ordering. Since Bit_Order is described in Chapter 13, all compilers should support it. However, the way GNAT (and perhaps other compilers) implement this is not the way I expected it. I expected on an Intel PC (little endian) when you say... for T'Bit_Order use System.High_Order_First; on a data type that has 'Size=32, that bit zero is the most significant bit (as it would be on an big endian sgi). That is NOT true. Bit zero is the MSB of byte zero (the least significant byte) of a four byte value. Basically, the storage place attributes ('Position, 'First_Bit, 'Last_Bit) are generated after normalizing the values so that 'First_Bit is less than Storage_Unit. So something like... for C at 0 range 24..24; with Storage_Size =8, you compute 'Position=3, 'First_Bit=0, 'Last_Bit=0. This is the most significant bit in a 32 bit value if you applied High_Order_First to the bit order. [sigh] It is a pain to define structures that are portable between both big and little endian machines. Almost as big a pain as the related byte swapping that is often needed. If someone wants a more detailed explanation of what we found w/ this, I suggest starting a new thread. --Mark